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ABSTRACT 


This  thesis  develops  a  methodology  to  identify  and  employ  elements  of  the  user’s  context  in  the  help 
system  architecture,  thereby  improving  the  response  provided  by  the  online  help  system.  Typical  online  help 
system  structures  are  static,  providing  a  pre-programmed  response  to  a  specific  assistance  request  and  are  not 
effected  by  the  dynamics  of  the  user  or  the  task  being  attempted.  A  dynamic,  context-driven  help  system  has 
been  developed  that  uses  user-  and  system-based  components  of  the  working  environment  to  influence  the 
system  access  and  presentation  strategies.  The  provided  response  is  tailored  specifically  to  the  user,  based  on 
the  user’s  level  of  experience  and  help  system  command  history;  and  specifically  to  the  situation,  based  on 
the  task  being  attempted.  The  resulting  online  system  provides  a  more  flexible  interface  that  can  serve  the 
needs  of  all  types  of  users  and  can  evolve  as  the  user's  skill  with  the  application  grows. 

The  dynamic,  context-driven  help  system  methodology  is  explained  through  design  and  implementation 
of  a  prototype  help  system  for  an  interactive  software  environment  TAE+  Help  is  a  help  component  designed 
to  assist  users  of  the  Transportable  Applications  Environment  Plus  (TAE+).  It  is  initiated  separately  from 
TAE+  but  runs  concurrently  in  the  XWindows  environment.  When  the  user  requests  assistance.  TAE+  Help 
initiates  a  dialogue  with  the  user,  collecting  situational  environmental  information  and  employs  these 
dynamics  in  the  help  system  access  process. 
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L  INTRODUCTION 


Despite  being  the  target  of  considerable  attention  for  the  last  ten  years,  there  is  still  little  consensus 
regarding  exactly  what  factors  are  the  critical  elements  in  designing  an  effective  help  system.  To  be  effective, 
a  help  system  must  be  flexible  enough  to  serve  the  needs  of  all  users,  from  the  beginning  user  to  the  highly 
experienced.  The  following  sections  discuss  the  basic  help  system  structures  and  what  information  is  used  by 
the  system  to  generate  the  assistance  response. 

A.  CHARACTERISTICS  OF  HELP  SYSTEMS 

Borenstein  [BOREN  85]  defines  an  online  or  interactive  help  system  to  be  “computer  software  that  has 
as  its  primary  function  the  task  of  providing  the  user  with  information  that  will  assist  in  the  use  of  some  other 
software  system.”  The  typical  help  system  is  designed  to  execute  quickly  and  provides  a  set  answer  in 
response  to  an  explicit  user  request.  The  objective  is  to  improve  the  user's  knowledge  and  proficiency  with 
the  application.  Variations  in  the  user-help  system  process  include  the  help  mechanism;  that  is.  how  the  help 
system  is  accessed,  the  question  being  submitted,  the  user  asking  the  question  and  the  situation  from  which 
the  question  emerges. 

Houghton  states  in  [HOUGH  90]  that  most  help  systems  are  initiated  by  the  user  explicitly  entering  a 
command-based  request  -  for  example  “help  ccommand  name>”.  The  <command  name>  is  then  used  by  the 
help  system  as  an  index  to  access  the  help  text  database.  If  the  provided  <command  name>  is  a  valid  element 
of  the  system  vocabulary,  the  assistance  text  is  displayed;  if  not,  an  error  message  is  presented  to  the  user.  The 
help  provided  usually  concentrates  on  the  syntax  of  the  commands,  occasionally  giving  examples,  but  rarely 
explains  how  the  command  fits  into  the  framework  of  the  whole  application  or  discusses  related  commands 
[GWEI 90]. 

During  the  system  design  phase,  assumptions  are  made  regarding  the  amount  of  computer  and  topical 
experience  the  typical  user  will  bring  to  the  session.  Assistance  texts  are  written  with  this  “homogeneous 
user”  [MOILY  87]  model  in  mind  and  result  in  a  help  structure  which  has  both  a  single  retrieval  methodology 
and  a  preset  presentation  strategy.  Hence,  the  depth  of  information  provided  is  invariant  and  therefore  is  not 
impacted  either  by  the  individual's  experience  or  ability. 

When  the  help  ystem  is  initiated,  system-related  information  such  as  the  hardware  system  in  use.  the 
operating  system  environment  and  the  application  being  used,  is  captured.  This  environmental  snapshot 
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provides  most  of  the  system-based  influence  on  the  help  system  access  process  in  a  typical  help  system 
structure.  The  user  request,  containing  the  command  name  for  which  help  is  requested,  provides  the  only 
varying  component  to  the  help  system  access  equation.  The  help  system  builds  the  help  response  by 
combining  the  system-based  framework  with  the  command  request  and  displays  the  pre-programmed 
response  to  the  user.  If  the  user  requires  amplifying  information  or  information  on  related  actions  or 
commands  a  subsequent  help  request  must  be  initiated. 

B.  INFORMATION  USED  BY  HELP  SYSTEMS 

The  typical  help  system  structure  does  not  use  user  or  situation-specific  information  to  tailor  the  help 
system  access  or  presentation  strategies.  The  most  basic  structure,  the  command-keyword-request  structure, 
is  referred  to  as  “static”  because  the  help  provided  in  response  to  a  specific  assistance  request  is  pre¬ 
programmed  and  is  not  effected  by  the  dynamics  of  the  user  or  the  task  being  attempted  [BOREN  85]. 
However,  additional  system-  and  user-based  variables,  such  as  application  mode  in  use,  the  command  history 
of  the  session  and  user  experience,  can  be  leveraged  to  provide  a  dynamic,  user-adaptive  element  to  the  help 
system  structure.  Knowing  the  application  mode  being  applied  provides  an  additional  layer  of  scope  defining 
information  that  enables  the  help  system  to  more  closely  focus  the  retrieval.  Focusing  the  retrieval  refers  to 
the  ability  of  the  system  to  determine  and  select  for  presentation,  the  help  text  component  that  most  closely 
fits  the  user’s  help  request.  For  example,  if  the  user  is  working  in  a  word  processing  application  and  wants 
information  about  formatting,  the  help  system  will  have  to  provide  all  format-related  help  text.  However,  if 
the  application  mode  in  use  is  known  to  be  “format  paragraph”,  the  assistance  need  can  be  more  closely 
predicted  and  the  response  tailored  to  provide  help  information  related  to  the  formatting  of  paragraphs  instead 
of  merely  defaulting  to  providing  information  regarding  formatting  in  general. 

Duffy  and  Langston  in  [DUFFY  85]  put  forward  one  of  the  more  comprehensive  discussions  regarding 
employing  elements  of  the  user  environment  in  help  systems.  They  discuss  the  “dynamism”  of  a  help  system, 
or  “the  degree  to  which  [the  help  system]  can  assess  and  respond  to  the  user's  needs  of  the  moment”  and 
further,  they  state  that  this  is  sometimes  referred  to  as  “context-sensitivity”.  The  system  msponse  is 
formulated  not  only  by  considering  the  user’s  explicit  request  but  also  by  factoring  in  elements  related  to  the 
specific  user  and  to  the  situation  that  lead  up  to  the  request.  By  employing  user-  and  situation-specific,  or 
context,  elements  in  the  help  system  structure,  the  help  system  has  a  representation  of  the  user  environment 
available  to  it  for  use  in  generating  help  responses  that  are  more  appropriate  for  the  user  and  the  situation. 
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C.  ISSUES  ADDRESSED  BY  DYNAMIC,  CONTEXT-DRIVEN  HELP  SYSTEMS 

By  definition,  adynamic-based  system  is  more  complex  to  build  and  maintain  than  a  static  help  system 
structure.  Therefore,  in  order  to  justify  the  additional  effort,  some  advantage  must  be  offered  by  the  dynamic 
structure.  The  following  sections  address  issues  involved  in  considering  a  dynamic  instead  of  static  help 
system  structure. 

One  of  the  issues  in  developing  a  dynamic-context  based  help  system  is  determining  what  types  of 
assistance  needs  can  be  answered  by  a  dynamic  system  that  can  not  be  served  or  served  as  well  by  the  more 
typical  static  system  structure.  Assistance  needs  addresses  both  the  types  of  questions  the  user  asks  (How  do 
you....?.  How  can  I  use....?.  What  do  I  do  next?,  etc.)  as  well  as  the  type  of  help  that  is  needed  (general, 
specific,  high-level,  detailed,  etc.).  Dynamic  structures  can  assist  the  user  in  determining  the  question  that 
needs  to  be  asked.  For  example,  at  times  the  user  may  be  unable  to  determine  which  menu  selection  will 
provide  the  information  needed  to  accomplish  the  job  being  attempted.  In  tins  situation,  the  help  system 
mechanism  needs  to  provide  a  means  of  prompting  or  assisting  the  user,  by  leveraging  the  available 
situational  information,  to  lead  them  to  die  question  they  are  attempting  to  ask. 

Dynamic  architectures  can  also  support  multiple  perspectives  from  which  questions  may  be  asked. 
Each  person  may  think  of  the  task  in  different  ways:  one  person  may  think  of  the  task  in  terms  of  a  particular 
system  function,  the  next  may  think  of  it  in  relation  to  the  other  work  being  done.  The  help  system  must  be 
able  to  provide  a  mechanism  for  the  user  to  use  to  map  the  mental  and  physical  pictures  together.  The  way 
the  menu  is  designed  can  provide  a  mechanism  to  link  the  user's  mental  representation  of  the  problem  to  the 
help  system  structure. 

Finally,  in  addition  to  responding  to  the  explicit  request  of  the  user,  dynamic  structures  also  have  the 
ability,  menu  structures  that  adapt  based  on  the  task  being  attempted,  to  assist  the  user  in  determining  the 
next  step  in  a  task  sequence.  Additionally,  they  provide  an  indicator  to  the  user  regarding  their  relative 
progress  in  completing  the  task  sequence.  The  menu  structure  must  be  able  to  provide  a  logical  representation 
of  the  how  the  application  is  used  and  should  frame  the  application's  commands  available  to  the  user  and  give 
some  indication  of  their  role  in  the  application. 

The  second  issue  relates  to  capturing  and  employing  the  user's  context  for  providing  more  specific  help 
to  the  use*-.  In  this  effort,  context  is  defined  to  mean  those  elements,  of  both  the  user  model  and  the  system 
that  form  a  representation  of  the  working  environment.  Capturing  the  context  entails  not  only  determining 
how  to  gather,  record  and  update  user  and  situation  elements  of  the  application  but  also  includes  determining 
what  elements  constitute  the  context  of  the  application  and  identify  the  essential  elements  of  the  user  model. 
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Once  the  decisions  regarding  how  and  what  to  capture  are  made,  the  next  step  is  determining  how  this 
information  can  be  employed  to  improve  the  way  the  help  system  access  mechanism  selects  which 
information  will  be  presented  to  the  user. 

Employing  the  ->r  t  s  context  in  focusing  the  help  system  entry  is  then  a  third  issue.  Once  captured,  how 
can  the  user's  context  be  employed  to  improve  the  help  system  entry  mechanism?  Static  systems  typically  use 
only  the  explicit  request  and  process  a  pre-programmed  help  text  retrieval.  By  employing  user-based 
■  formation  such  as  pre-existing  knowledge  and/or  system-based  information  such  as  the  specific  task  being 
attempted,  the  help  text  selection  process  can  tailor  the  response  to  the  user  and  the  user’s  work  situation. 
Tailoring  in  this  sense  means  adjusting  the  amount  of  information  presented  relative  to  the  specifics  of  the 
user  and  the  work  being  done. 

A  final  issue  addresses  formatting  the  help  text  to  serve  users  of  all  levels  of  experience.  The  design  of 
the  help  system  is  driven  by  the  user  model.  Therefore  the  more  user-related  information  that  can  be  captured, 
the  better  we  can  serve  the  needs  of  the  user.  The  typical  help  system  development  defines  the  characteristics 
of  the  expected/typical  user  during  to  the  system  design  phase  in  terms  of  the  type  and  amount.  A  common 
practice  is  to  present  the  help  information  using  the  same  structure,  regardless  of  whether  the  assistance  is 
being  provided  to  an  experienced  user  or  a  novice  and  with  no  regard  as  to  what  type  (general  or  detailed)  of 
information  is  being  requested.  A  dynamic  structure  can  provide  a  means  of  adjusting  the  information 
presented  to  more  closely  fit  the  needs  of  the  user,  providing  more  in-depth  information  to  the  novice  user, 
for  example. 

This  thesis  explores  these  questions  via  a  prototype  help  system  for  an  interactive  software 
environment.  TAE+  Help  is  a  help  component  designed  to  assist  users  of  the  Transportable  Applications 
Environment  Plus  (TAE+).  Development  of  the  prototype  was  accomplished  by  first  identifying  the  user-  and 
system-based  elements  of  TAE+  that  form  the  framework  of  the  application's  context  This  was  followed  by 
creating  mechanisms  to  first  gather  and  then  employ  the  context-related  variables  in  the  help  system  access 
and  presentation  strategies.  TAE+  was  selected  as  the  target  application  based  on  its  depth  and  breadth  of  the 
command  structure.  Additionally,  although  the  current  application  has  a  built-in  help  facility  to  respond  to 
“what  is  this?”  user  queries,  many  other  types  of  assistance  are  not  provided. 

Appendix  A  provides  a  synopsis  on  TAE+  V5.  i .  TAE+  Help  is  initiated  separately  from  TAE+  but  runs 
concurrently  in  the  XWindows  environment.  When  the  user  requests  assistance,  TAE+  Help  initiates  a 
dialogue  with  the  user,  collecting  situational  environmental  information  and  employs  these  dynamics  in  the 
help  system  access  process. 
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D.  THESIS  ORGANIZATION 


Chapter  II  of  this  thesis  provides  a  survey  of  selected  online  help  systems  in  general,  some  of  the  related 
criticisms  of  current  systems  and  a  taxonomy  to  frame  the  elements  of  typical  help  systems.  Chapter  III 
describes  the  methodology  employed  to  develop  a  dynamic,  context-driven  help  system  and  the  system 
developed  to  implement  these  concepts.  Finally.  Chapter  IV  presents  conclusions  and  recommendations  for 
future  research. 
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IL  SURVEY  OF  ONLINE  HELP  ISSUES 


Online  help  systems  are  but  one  element  of  the  much  broader  online  assistance  domain  that  also 
encompasses  online  documentation,  tutoring,  prompting  and  other  such  assistance  facilities,  that  element  that 
provides  a  detailed,  localized  assistance  for  the  domain  of  immediate  interest  to  the  user.  This  survey  is 
concerned  only  with  online  help  systems:  specifically,  it  defines  the  system  taxonomy  that  will  form  the  basis 
for  describing  help  systems  in  this  thesis.  Since  the  topic  of  context  is  central  to  the  thesis,  this  chapter 
discusses  the  role  that  context  and  user  experience  play  in  developing  a  help  system  separately  from  the 
taxonomy  even  though  one  potential  dimension  of  the  taxonomy  would  be  the  use  of  context.  Lastly,  this 
chapter  identifies  some  of  the  deficiencies  of  current  help  systems. 

A.  TAXONOMY 

Help  systems  can  be  characterized  on  a  number  of  dimensions:  1)  access  initiative,  the  means  by  which 
the  help  system  is  invoked;  2)  help  mechanism,  the  interface  medium  between  the  user  and  the  help  system; 
and  3)  help  system  implementation,  the  structures  used  to  build  the  help  system. 

1.  Access  Initiative 

Help  assistance  can  be  initialed  by  the  human  user,  the  system  or  some  combination  of  both. 
Systems  are  classified  in  terms  of  access  initiative  by  categorizing  them  based  on  the  degree  to  which  the 
system  is  user-  versus  system-initialed.  The  vast  majority  of  systems  are  user-initiated,  that  is.  help  text  is 
provided  after  a  help  request  is  explicitly  entered  by  the  user  -  for  example  “help  <command  name>".  Systems 
that  supports  both  user-  and  system-initiated  help  are  call  mixed-initiative  systems.  An  example  of  a  mixed- 
initiative  system,  is  the  WEST  system  [BURTO  82],  which  monitors  the  user’s  actions  and  compares  the 
decisions  the  student  makes  to  the  expert  module.  The  help  structure  provides  recommendations  for  more 
advantageous  moves  or  actions,  as  warranted  by  the  user’s  actions,  as  well  as  provides  textual  help  in 
response  to  an  explicit  user  request.  The  final  type  of  help  initiation  would  be  a  help  component  that  initiates 
all  help  assistance.  There  is  no  facility  by  which  the  user  can  request  assistance;  instead  the  system  controls 
the  entire  operation  and  initiates  further  activity  as  needed. 
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2.  User-Initiated  Help  Mechanism 

The  help  mechanism  is  the  interface  mechanism  by  which  the  user  relates  to  the  help  system. 
Possible  mechanisms  include  command-keyword-request,  menu-selection,  active  screen  buttons,  natural- 
language  request  and  spoken-phrase  request  Command-keyword-requests  are  the  most  common  form  of  help 
mechanism  ([GWEI 90]  and  [HOUGH  90])  and  require  the  user  to  enter  “help”  followed  by  the  command 
they  are  requesting  assistance  for.  Novice  users  have  the  greatest  difficulty  effectively  using  this  type  of  help 
system  due  to  the  implicit  requirement  to  have  pre-existing  knowledge  about  the  system  and  its  commands 
[GWEI  90].  Menu  selection  provides  the  user  with  a  list  of  the  available  help  topics  from  which  a  choice  can 
be  made.  This  mechanism  provides  more  assistance  for  the  novice  by  providing  a  visible  list  of  the  available 
commands  but  still  doesn't  assist  in  the  issue  of  relating  the  commands  to  the  task  at  hand  and  also  is  often  a 
source  of  frustration  to  the  experienced  user  forced  through  a  time-intense  access  process.  A  mechanism  that 
is  becoming  more  common  is  designing  user-interface  screens  with  areas  on  the  screen  that  function  as 
buttons.  When  these  buttons  are  selected  (usually  by  pointing  and  clicking  with  a  mouse),  help  texts  are 
shown  explaining  the  item  and  its  purpose  relative  to  the  application.  This  mechanism  can  be  effective  for  the 
user  “exploring”  the  application  but  is  less  helpful  when  the  user  has  a  specific  task  in  mind  and  is  searching 
for  the  appropriate  command  to  accomplish  it  Technology  in  the  intelligent  and  expert  system  arenas  is 
making  advances  on  providing  two  additional  mechanisms:  natural-language  requests  and  spoken-phrase 
requests.  Natural-language-requests  allow  the  user  to  enter  a  request  in  the  form  of  a  sentence  that  the  system 
then  analyzes  [GWEI  90].  Spoken-phrases  incorporate  speech  recognition,  taking  an  orally-spoken  request 
and  parsing  it  for  keywords.  To  date,  spoken-phrases  have  been  successfully  applied  only  in  limited  domains 
[BOREN  85].  At  a  minimum,  systems  usually  include  a  command-keyword-request  help  component  and 
frequently  have  multiple  help  mechanisms,  for  example,  command-keyword-request  and  menu-selection 
mechanisms. 

3.  Help  System  Architecture 

Another  element  of  help  system  development  that  varies  significantly  is  the  amount  and  type  of 
structural  mechanisms  that  are  used  in  building  the  help  system.  Two  variants,  the  utility  of  which  is  still 
being  addressed  in  current  literature,  are  the  ideal  number  of  levels  of  assistance  to  provide  to  the  user  [GWEI 
90],  [CHERR  89]  and  [FARRA  92],  and  whether  or  not  the  help  system  should  be  part  of  the  application  or 
part  of  the  system  as  a  whole  [BOREN  85]. 
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a.  Single-  versus  Multiple-Leveling 


A  help  system  structure  may  be  designed  to  provide  a  single  level  or  multiple  levels  of 
assistance.  An  example  of  a  single  level  system  is  the  UNIX  “man”  (manual)  command  that  provides  a  copy 
of  the  online  manual  text  in  response  to  the  user  query.  The  help  text  may  include  a  recommendation  to 
reference  related  commands  but  any  subsequent  help  assistance  must  be  initiated  by  the  user  with  an 
additional  "man”  command  [GWEI 90].  Other  systems  employ  a  hierarchial  menu  arrangement  of  topics  and 
subtopics  [CHERR  89]  to  facilitate  navigation  through  an  electronically  linked  set  of  help  texts.  Links  may 
be  designed  to  enable  the  user  to  access  more  detailed  texts  of  the  help  topic  or  to  access  related  topic  help 
information.  A  single  level  of  help  provides  a  simple,  easy  to  understand  help  structure.  Farrand  and  Wolfe 
in  [FARRA  92]  argue  that  the  objective  should  be  to  provide  simpler  and  fewer  types  of  help.  However, 
single-level  structures  sacrifice  the  power  of  the  multi-level  structures.  Use  of  just  one  additional  level 
provides  a  mechanism  for  grouping  topics  under  higher-level  titles  and  reduces  the  cognitive  complexity  of 
the  access  interface. 

b.  Integrated  and  Integral  Help  System  Implementation 

Many  systems  provide  several  online  help  system  access  mechanisms,  for  example, 
command-keyword  request  and  menu  selection.  The  level  of  integration  refers  to  the  degree  of  independence 
the  different  help  mechanisms  operarate  under.  If  all  system  help  components  access  the  same  database  and 
enable  the  user  to  query  on  any  topic  independently  of  the  task  at  hand,  it  is  a  fully-integrated  help  system. 
[BOREN  85]  More  commonly,  each  application  has  its  own  help  system  and  a  help  text  database  that  is 
accessed  only  when  the  user  is  working  within  the  application. 

“An  integral  help  system  is  one  in  which  the  help  is  provided  by  the  same  program  that 
executes  the  commandfBOREN  85].  In  other  words,  the  help  system  is  invoked  from  within  the  application 
and  is  actually  a  part  of  the  application  as  opposed  to  being  part  of  the  system  that  runs  the  application.  The 
advantages  of  non-integral  help  systems  include  providing  the  user  with  a  consistent  interface  that  is 
accessible  from  all  applications  and  often  a  more  comprehensive  help  mechanism  vice  the  application- 
specific  help. 
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B.  ACCESSING  THE  HELP  SYSTEM 
1.  T^pes  of  User  Queries 

Sellen  and  Nicol  conducted  a  number  of  studies  to  determine  what  types  of  questions  users  asked. 
They  were  able  to  group  the  queries  into  five  broad  classes  of  questions  as  depicted  in  Figure  1 .  These  classes 
will  be  used  in  subsequent  discussions  throughout  this  thesis. 


1.  Goal-oriented 

2.  Descriptive 

3.  Procedural 

4.  Interpretive 

5.  Navigational 


What  kinds  of  things  can  I  do  with  this  program? 

What  is  this?  What  does  this  do? 

How  do  I  do  this?  How  do  I  accomplish  a  specific  operation? 
V/hy  did  that  happen?  What  does  this  mean? 

Where  am  I? 


Figure  1.  Classes  of  Help  Questions  [SELLE  90] 


In  general,  goal-oriented  and  descriptive  queries  are  used  by  novice  users  in  the  process  of 
familiarizing  themselves  with  the  application  and  system.  Visibility  of  the  existence  of  the  help  component 
and  ease  of  access  are  more  important  aspects  than  efficiency,  as  these  help  components  are  referenced 
relatively  infrequently  by  any  one  user,  but  may  be  critically  important  when  they  are.  Procedural  queries  are 
the  most  common  type  of  queries  [SELLE  90]  and  are  used  more  frequently  in  general  and  by  all  categories 
of  users.  Therefore,  access  mechanism  efficiency  and  ease-of-use  are  important  elements  in  providing 
appropriate  help  information  in  a  format  useful  to  all  users.  Interpretive  and  navigational  questions  relate  to 
why  and  where  elements  in  help  systems.  These  help  elements  are  still  relatively  novel  components  in  today's 
help  system  arena. 

Two  observations  related  to  online  help  systems  emerge:  First,  “the  kind  of  information  delivered 
should  be  different  depending  on  the  (type  of)  question  asked"  (or  implied)  [SELLE  90].  A  user  asking  a 
procedural  question  is  likely  looking  for  specific,  pointed  information,  while  a  request  for  goal-oriented 
information  indicates  more  expansive  help  may  be  appropriate.  Second,  “the  way  in  which  information  is 
accessed  and  presented  should  depend  on  the  question  asked"  [SELLE  90].  A  request  initiated  by  a  pointing 
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action  is  likely  a  descriptive  query.  Contrast  this  with  a  command-keyword  request.  The  latter  inquiry  is  likely 
more  procedurally  oriented,  the  former  more  of  a  descriptive  query.  In  each  situation  the  type  of  questions 
and  the  manner  in  which  the  users  ask  them  are  factors  that  can  be  employed  in  the  help  system  design 
process. 

2.  Task-Based  versus  Function-Based  Menu  Orientation 

Jackson,  Cherry  and  Fryer  in  [CHERR  89]  describe  a  task-based  menu  structure  that  maps  the 
order  of  menu  topic  titles  to  the  sequence  of  typical  activities  that  a  user  must  perform  to  accomplish  a  major 
goal.  The  grouping  of  titles  gives  the  user  a  high  level  view  of  the  whole  task  and  of  the  sequence  of  events 
required  to  accomplish  the  work.  The  objective  of  this  type  of  menu  structure  is  to  assist  new  users  in 
becoming  productive  quickly.  Additionally,  the  structure  provides  an  efficient  access  mechanism  for 
experienced  users  with  a  specific  request.  A  function-based  menu  provides  an  alphabetical  listing  of  all  of  the 
available  application  commands.  Novice  users  have  a  more  difficulty  using  this  type  of  help  system  as  it 
provides  no  assistance  to  the  novice  user  attempting  to  determine  which  commands  are  needed  to  accomplish 
the  task  being  attempted  [CHERR  89]. 

C.  THE  ROLE  OF  CONTEXT 

Duffy  and  Langston  [DUFFY  85]  define  the  “dynamism"  of  a  help  system  to  be  “the  degree  to  which 
[the  help  system]  can  assess  and  respond  to  the  user’s  needs  of  the  moment”  and  further,  they  state  that  this 
is  sometimes  referred  to  as  “context-sensitivity”.  Although  the  term  “context-sensitive”  has  been  used  for 
many  years  in  discussions  related  to  help  systems,  a  universally-agreed-upon  meaning  has  not  yet  emerged. 

Relies  and  Sondheimer  [RELLE  81]  describe  characteristics  of  effective  online  help  systems  to  include 
“context  sensitivity  -  the  ability  to  provide  assistance  relevant  to  the  user's  current  situation”.  When  referring 
to  context,  they  speak  of  environmental  information  related  to  the  user,  the  application  and  the  tasks  being 
performed.  Houghton  [HOUGH  90]  espouses  that  the  employment  of  context  would  be  one  way  to  make  the 
help  system  less  disruptive  and  thus  assist  the  user  in  maintaining  the  mental  context  of  the  work  environment 
while  accessing  the  help  environment  Maass  [MAASS  83]  declares  that  systems  in  general  should  be  able  to 
maintain  a  “self-image”  of  their  current  state  and  provide  explanations  to  the  user  about  current  alternatives 
and  expected  formats;  this  to  be  accomplished  by  providing  a  context-sensitive  help  system.  Sellen  and  Nicol 
[SELLE  90]  postulate  that  the  more  context-sensitive  help  can  be  made,  the  less  obtrusive  it  will  be  for  users. 
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Burton  and  Brown  in  [BURTO  82]  describe  a  expert,  computer-based  coaching  system,  “How  the  West 
was  Won”  that  gathers  the  context  of  the  player’s  game  by  monitoring  the  moves  the  player  makes.  These 
are  compared  to  expert  module  where  an  evaluation  is  done  to  assess  the  quality  of  the  move. 

All  systems  can  be  characterized  based  on  the  use  of  context  by  using  a  continuum  ranging  from  static 
help  systems,  typified  by  the  conventional  command-keyword-request  system,  to  dynamic  systems  like 
intelligent  or  knowledge-based  systems.  The  command-keyword-request  system  is  referred  to  as  “static” 
because  the  help  provided  in  response  to  a  specific  assistance  request  is  not  altered  by  user  characteristics  or 
actions.  In  knowledge-based  systems  some  combination  of  user  experience,  the  most  recently  entered 
command  and/or  command  history  is  employed  by  the  system  to  determine  what  type  or  amount  of  help  is 
needed  and  therefore  is  characterized  as  dynamic. 

D.  USER  EXPERIENCE 

An  additional  element  is  often  discounted  when  discussing  help  systems:  user  experience,  the  amount 
of  both  computer  and  topical  experience  the  user  brings  to  bear  in  system  interactions.  Relatively  few  of  the 
authors  substantially  address  the  variation  in  the  type  and  amount  of  assistance  that  is  required  by  an 
experience-diverse  target  audience,  often  stating  only  that  the  help  system  must  serve  all  types  of  users.  The 
expected  proficiency  of  the  user  should  weigh  heavily  in  design  decisions,  effecting  everything  from  the 
amount,  type  and  format  of  the  provided  information  to  the  topic  organization  and  access  mechanism. 
Unquestionably,  the  “novice-novice”,  a  user  inexperienced  in  both  computer  use  and  the  specific  application 
requires  more  in-depth  assistance  than  the  “experienced-novice”,  a  user  experienced  with  computers  but  not 
the  application.  These  needs  will  also  vary  significantly  from  those  of  the  “experienced-experienced”  user  in 
search  of  very  specific  assistance,  for  example,  command  syntax. 

E.  SHORTFALLS  OF  CURRENT  HELP  SYSTEMS 

Several  authors  catalogue/detail  deficiencies  of  current  help  systems  or  propose  critical  elements  to 
consider  in  designing  new  systems.  Shortfalls  that  are  often  cited  of  help  systems  include: 

-  users  are  required  to  sift  through  large  verbose  help  texts  for  relevant  information  [BOREN  85] 

-  users  must  have  knowledge  of  the  available  commands,  their  relevance  to  the  task  at  hand  and  the 
command  syntax  [GWEI 90J. 

-  users  are  required  to  physically  as  well  as  mentally  switch  contexts  from  the  work  context  to  the  help 
system  context  [RIDGW  87], 
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-  users  are  provided  with  a  'canned'  help  text  response,  that  is,  the  type  and  amount  of  information  is  not 
influenced  by  the  state  of  the  user’s  environment  or  skill  [MOELY  87]  and  often  is  too  general  to  be  of  any 
assistance. 

-  users  aren’t  able  to  determine  which  commands  and  actions  are  needed  to  accomplish  the  task  being 
attempted  [CHERR  89]. 

The  single  message  arising  from  the  plethora  of  help  design  and  implementation  articles  is  that  there 
still  is  little  consensus  in  the  field  as  to  what  the  characteristics  of  a  good  help  system  are.  In  fact,  Borenstein 
[BOREN  85]  concluded  “...help  systems  in  general  use  are  so  uniformly  unappealing  that  designers  who  do 
make  an  effort  to  construct  wonhwhile  help  systems  tend  to  assume  that  they  are  starting  with  a  clean  slate, 
working  on  a  problem  that  has  never  been  seriously  confronted  before....” 

Dynamic,  context-driven  help  system  improvements  proposed  in  the  previous  chapter  have  the  potential 
for  relieving  many  of  these  deficiencies.  The  improved  access  mechanism  will  result  in  a  more  focused 
retrieval  and  a  response  that  is  more  relevant  to  the  situation.  Additionally,  user-specific  information  is  used 
throughout  the  access  and  presentation  processes  to  tailor  the  response  to  the  experience  level  of  the  user. 
Improved  menu  structures  will  provide  a  means  of  presenting  a  structured  command  list  showing  the  user  not 
only  the  commands  available  for  use  but  also  will  provide  a  framing  mechanism  indicating  the  role  the 
commands  play  in  the  application.  By  employing  user-  and  situation-specific,  or  context,  elements  in  the  help 
system  structure,  the  help  system  has  a  representation  of  the  user  environment  available  to  it  for  use  in 
generating  help  responses  that  are  more  appropriate  for  the  user  and  the  situation. 

F.  CONCLUSION 

This  chapter  has  presented  the  user  with  a  taxonomy,  or  framework,  for  discussing  help  systems  and  has 
discussed  the  role  of  user  experience  and  context  in  recent  help  system  literature.  Additionally,  deficiencies 
cited  by  displeased  users  are  presented  attempting  to  project  the  magnitude  of  the  problem.  The  next  chapter 
discusses  the  steps  necessary  to  develop  a  dynamic,  context-driven  help  system  and  offers  a  prototype  to 
demonstrate  the  advantages  the  dynamic  structure  offers  over  more  typical  help  system  structures. 
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HI.  DYNAMIC,  CONTEXT-DRIVEN  HELP  SYSTEMS 


The  initial  step  in  developing  a  dynamic,  context-driven  help  system  is  to  identify  the  elements  of  the 
application  environment  that  form  the  framework  of  the  application’s  context.  The  help  system  must  first 
gather  and  track  these  context  elements  and  then  incorporate  them  into  the  help  system  access  decision 
mechanisms  to  provide  an  improved  help  system  structure.  TAE+  Help  has  been  developed  to  demonstrate 
the  viability,  feasibility  and  utility  of  a  dynamic-context  driven  help  system.  System  development  excerpts 
will  be  referenced  periodically  throughout  this  thesis.  Appendix  A  provides  a  synopsis  of  the  Transportable 
Applications  Environment  Plus  (TAE+)  software  development  environment  application. 

A.  IDENTIFYING  CONTEXT 

Context,  as  defined  for  use  in  this  thesis,  consists  of  two  components,  system-based  context  and  user- 
based  context.  System-based  context  elements  are  identified  by  actual  examination  and  recording  of  the 
system  in  question;  user-based  context  identification  is  accomplished  by  projecting  information  regarding  a 
typical/hypothetical  user  of  the  application.  The  following  sections  provide  the  details  of  this  process. 

1.  Identifying  System-Based  Context 

Two  steps  are  required  to  identify  and  record  the  elements  of  a  system  that  define  the  system-based 
context.  The  first  step  entails  developing  state-transition  diagrams  (STDs)  to  model  the  system  behavior  of 
the  application  that  the  help  system  is  being  developed  for.  STDs  depict  the  path(s)  through  which  each  state 
can  be  reached,  the  possible  transitions  out  of  the  state,  the  catalyses)  that  cause  each  transition  and  the 
subsequent  state  that  results  from  the  transition.  These  STDs  are  then  employed  in  the  second  development 
step  to  isolate/identify  system  functions  and  actions  supported  within  each  state.  Appendix  B  provides  STDs 
generated  to  model  applicable  portions  of  TAE+.  TAE+  Help  STDs  associate  a  state  with  each  TAE+ 
window/subwindow. 

Each  STD  state  is  examined  individually  to  identify  and  record  the  questions  the  user  may  ask/ 
have  while  working  in  the  state.  Sellen  and  Nicol  in  [SELLE  90]  define  five  types,  or  classes,  of  help-related 
questions  users  typically  ask;  goal-oriented,  descriptive,  procedural,  interpretive  and  navigational.  A  table  is 
constructed  that  cross  references,  by  question  class,  the  questions  discovered  in  each  state  and  the  STD  state 
they  apply  to.  In  addition  to  the  organizational  benefit,  this  question-state  table  construct  provides  a  check- 
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and-balance  mechanism  to  ensure  comprehensive  coverage  of  the  state  assessment  process.  The  developer 
fust  lists  the  questions  that  arise  after  the  initial  review  of  the  state  and  groups  them  according  to  the  five- 
class  structure.  Then  the  content  of  the  resulting  question-state  table  is  reviewed  from  the  perspective  of  each 
class  of  question,  to  ascertain  all  probable  questions  have  been  included.  The  content  of  the  question-state 
table  then  becomes  the  foundation  document  for  development  of  a  three-tiered  menu  system  that  will  be  used 
to  gather  the  user’s  working  context  Appendix  C  provides  the  question-state  table  containing  the  questions 
that  arise  at  each  TAE+  state.  TAE+  V5.1  supports  the  descriptive  questions  within  the  current  application 
and  thus  they  have  not  been  included  in  this  effort 

A  second  table  is  constructed  for  recording  visible  objects,  or  observables,  such  as  subwindow(s) 
titles,  icons,  operating  mode  setting,  etc.,  within  the  state  that  are  state-specific.  The  observables-table 
structure  also  includes  developer  notes  regarding  supplementary  questions  that  may  be  asked  of  the  user  to 
more  closely  pinpoint  the  context  elements  where  there  remains  a  lot  of  context  ambiguity.  Appendix  D 
provides  a  table  of  the  observable  context  clues  associated  with  each  TAE+  state. 

These  two  table  structures  represent  two  of  the  system-based  context  elements  that  must  be 
captured  and  employed  in  the  developmental  help  system.  The  final  system-based  component  is  the 
application  mode  in  use.  Typically,  the  application  mode  categories  offer  a  high-level,  system-partitioning 
mechanism  that  can  be  used  to  quickly  reduce  the  search  list  of  potential  topics  that  must  be  considered  during 
the  help  system  access  process.  If  the  application  mode  being  applied  is  known,  entire  sections  of  the  system 
can  be  dismissed  during  the  initial  topic  honing  effort,  leaving  a  smaller,  more  manageable  quantity  to  address 
in  subsequent  searches.  The  more  closely  the  target  topic  can  be  pinpointed  during  the  access  process,  the 
more  request-applicable  the  information  that  can  be  provided  to  the  user.  The  next  component  that  is 
addressed  is  identification  of  the  user-based  context  elements. 

2.  Identifying  User-Based  Context 

User-based  context  elements,  when  considered  together,  form  the  user  model  that  will  be  assumed 
throughout  the  development  The  model  should  profile  the  typical  user  of  the  application;  in  the  case  of  a  help 
system,  this  still  infers  a  very  broad  range  of  capabilities/knowledge  that  must  be  provided  for.  Elements  to 
consider  include  user  experience  and  help-system-command  execution  history. 

a.  User  Experience 

The  amount  of  previous  experience  the  user  brings  to  the  session  contributes  significantly  to 
decisions  regarding  how  much  help  information  is  provided  to  the  user  in  reply  to  a  request  for  system  help 
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and  the  manner  in  which  >$  presented.  For  example,  novice  users  need  more  intuitive  menu  selections  to 
choose  from  and  in  the  case  of  requests  for  very  specific/nairow  scope  information,  it  may  be  advisable  to 
provided  additional  assistance  in  the  form  of  more  general  topic  help.  Also,  previous  experience  may  not 
necessarily  be  directly  related  to  the  target  application  in  order  to  be  considered  significant.  An  additional 
type  of  experience  available  for  use  in  the  access  decision  process  arises  if  the  topic  in  question  in  some  way 
relates  to  another  topic  that  the  user  may  be  familiar  with.  In  this  instance,  the  provided  help  text  can  be 
presented  in  terminology  relating  the  known  topic  to  the  requested  topic,  assisting  the  user  in  using  pre¬ 
existing  knowledge  to  interpret  and  understand  the  new  situation. 

b.  Menu  Selection  History 

Topic  selection  and  the  history  of  topics  selected  by  the  user  are  also  important  elements  in 
the  help  system  access  process.  The  user’s  topic  selection  itself  indicates  the  explicit  user  request  and  may 
also  imply  the  application  development  stage  that  the  user  is  currently  working  on.  However,  the  history  of 
topics  selected  implies  additional  information  about  what  assistance  the  user  may  need.  For  example,  if  the 
user  is  a  novice  and  has  not  requested  or  been  shown  general  information  about  a  concept,  responding  directly 
to  a  very  specific  topic  request  may  not  be  adequate.  It  may  be  advisable  to  preface/supplement  the  specific 
topic  response  with  a  broader  topic  discussion  segment  to  clarify  its  full  role  in  the  application. 

B.  GATHERING  CONTEXT 

Once  the  meaningful  elements  of  the  context  are  identified,  they  must  be  collected  and  tracked  for  use 
in  the  help  system  access  decision  process.  System-based  context  elements  are  gathered  by  recording  the 
application  mmode  and  menu/submenu  selections  made  by  the  user.  User-based  elements  are  gathered  by 
monitoring  the  skill  level  and  past  experience  of  the  user. 

1.  Gathering  System-Based  Context 

A  three-tiered  menu  system  is  used  to  create  a  multi-prospective  view  of  the  target  application 
system  for  the  user.  By  monitoring  the  menu  topic  selections  made  by  the  user  a  context  model  can  be 
constructed  and  used  as  the  basis  for  determining  what  topic  the  user  is  interested  in. 

a.  Subwindow  Menu 

The  highest-level  menu  structure,  the  Subwindow  Menu,  is  developed  from,  and  ordered  by, 
the  hierarchy  of  the  application's  subwindow  titles.  The  user  selects  the  menu  title  that  cc ■  responds  with  the 
title  of  the  application  subwindow  being  worked  in.  Embedded  submenus  prompt  the  user  for  more 
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information  regarding  their  help  request  by  projecting  lists  of  probable  topics  and  thereby  provide  a 
mechanism  for  capturing  more  of  the  user’s  working  context.  The  Subwindow  Menu  provides  the  user  with  a 
very  efficient  help  access  mechanism,  directly  mapping  the  question-related  application  window  to  the  help 
structure  and  quickly  focusing  the  help  topic  lists  to  the  probable  topic  area.  Supplemental  submenus, 
embedded  within  the  subwindow  structure,  enable  remaining  topic  ambiguity  to  be  further  reduced. 

b.  Task-Oriented  Menu 

The  second  tier,  the  Task-oriented  Menu,  is  ordered  based  on  the  sequence  of  tasks 
accomplished  during  a  typical  development  The  user  selects  the  menu  title  that  corresponds  with  the  task 
currently  being  worked  on  or  for  which  information  is  being  requested.  Supplementary  questions  may  be 
asked  to  determine  if  the  user  has  any  other  direct/indirect  experience  that  may  be  leveraged  to  best  answer 
the  current  request  The  user  is  able  to  relate  the  task  being  accomplished  directly  to  the  menu  structure, 
providing  an  indicator  of  what  the  user’s  working  context  is  now,  what  the  next  context  is  likely  to  be  and 
allows  suppositions  to  be  made  regarding  what  the  user  has  knowledge  of.  For  example,  in  TAE+  Help,  if  the 
user  is  currently  working  on  specifying  an  item,  it  can  be  assumed  that  the  tasks  related  to  resource  file 
manipulation  and  panel  specification  have  already  been  accomplished  by  the  user  and  it  is  probable  that  help 
requests  in  the  near  term  will  relate  to  the  details  of  building  and  placing  items. 

c.  Function-Oriented  Menu 

The  Final  tier,  the  Function-oriented  Menu  consists  of  an  alphabetical  listing  of  the  projected 
system  functions  that  have  been  derived  from  the  question-state  table  contents.  The  user  selects  the  menu  title 
that  best  represents  the  topic  for  which  help  is  being  requested.  The  function-oriented  listing  is  the  finest- 
grained  topic  listing,  providing  the  building  blocks  to  represent  all  the  atomic/fundamental  context  elements 
of  the  application.  Whereas  the  subwindow  and  task-oriented  structures  assist  in  the  capture  of  the  physical 
working  context  of  the  application,  the  function-oriented  structure  provides  a  capability  for  capturing  the 
user’s  mental  context  of  the  problem  in  situations  where  the  request  is  unrelated  to  the  current  physical 
context. 

The  three-tiered  menu  system  provides  the  user  with  a  help  system  configured  in  multiple  fashions, 
enabling  the  user  to  map  his  mental  picture  to  the  most  appropriate  help  view,  and  thereby  reducing  the  user’s 
cognitive  load  when  moving  between  the  work  and  help  environments.  The  sub  window  and  task  originated 
requests  use  their  respective  structures  to  support  the  gathering  of  the  context-based  elements  of  the  situation 
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and  pinpoint  the  primary  topic  title.  System  control  then  passes  to  the  function-oriented  structure  to  present 
the  requested  help  text  Access  to  the  menu  structures  is  provided  to  the  user  through  left-,  middle-  and  right- 
button  mouse  clicks  to  reach  the  Subwindow,  Task-oriented  and  Function-oriented  Menus  respectively. 

d.  Application  Mode 

The  application  mode  setting  information  is  gathered  during  the  initial  system  entry  process 
and  again  whenever  the  user's  topic  selection  indicates  the  application  utilization  has  moved  into  a  different 
mode.  In  TAE+  Help,  the  mode  the  user  starts  working  in  is  the  Move/Resize/Edit  mode.  Menu  lists  are 
ordered  to  first  present  the  topics  expected  to  be  encountered  by  the  user  working  in  that  mode.  If  the  user 
subsequently  requests  assistance  on  defining  Panel  connections  this  is  an  indicator  that  the  application  mode 
has  changed  or  should  be  changed  to  Define  Connections.  If,  in  fact,  the  development  has  progressed  to  the 
point  of  defining  connections  between  objects  and  panels,  a  further  supposition  can  be  drawn  that  the  topic 
lists  should  be  reordered  to  first  present  titles  related  to  defining  connections  and  other  tasks  that  fall  after  that 
point  in  a  typical  development  effort. 

2.  Gathering  User-Based  Context 

User-based  context  element  information  is  gathered  initially  upon  entry  into  the  system  and  then 
is  updated  dynamically  throughout  the  session.  Contributing  elements  include  user  experience  and  command 
history. 

a.  User  Experience 

The  initial  experience  level  setting  is  based  on  responses  to  an  experience  assessment 
conducted  when  the  user  first  enters  the  help  system.  Questions  designed  to  break  users  out  into 
distinguishable  levels  of  experience  are  presented  and  the  responses  are  used  to  derive  the  assigned 
experience  level.  In  the  case  of  TAE+  Help,  the  user  is  queried  as  to  the  extent  of  their  experience  in  the  use 
of  the  more  complicated  TAE+  capabilities.  Their  replies  are  then  used  to  classify  them  as  novice, 
experienced  or  knowledgeable  users.  Subsequent  application  use  adjusts  this  proficiency  variable 
dynamically  to  more  closely  map  the  demonstrated  user  skill  to  both  the  amount  and  type  of  provided 
information.  For  example,  if  the  user  replies  indicate  they  have  experience  with  several  of  the  more  advanced 
development  procedures,  the  user  is  classified  as  Knowledgeable.  However,  if  a  user  classified  as 
Knowledgeable  selects  very  fundamental  menu  topics,  the  user  will  be  re-classified  to  downgrade  the 
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assigned  experience  level  to  Experienced.  Conversely,  a  user  classified  as  Novice  will  automatically  be 
upgraded  to  Experienced  after  accessing  the  post-TAE+  Item  topics. 

b.  Menu  Selection  History 

The  command  selection  history  together  with  the  experience  level  of  the  user  are  the 
fund  .mental  factors  in  the  help  system  access  decision  process.  The  command  history  is  accumulated  by 
flagging  each  help  script  element  that  is  viewed  by  the  user.  In  TAE+  Help,  a  topic  is  flagged  as  shown  after 
being  viewed  by  the  user.  The  experience  level  of  the  user,  along  with  the  list  of  shown  topics,  contribute  to 
the  decisions  regarding  what  the  user  sees  in  response  to  the  current  request  and  when  the  experience  level  of 
the  user  is  modified/adjusted.  If  the  user  is  a  novice  user  and  is  requesting  assistance  on  a  very  specific  topic, 
a  check  is  done  to  see  whether  the  user  has  viewed  the  more  general  topic  script.  If  not.  the  general 
information  is  presented  and  is  followed  by  the  specific  topic  requested  by  the  user.  Further  details  of  this 
process  are  provided  in  the  following  sections. 

C.  USING  CONTEXT 

The  gathered  context  elements  are  used  and  updated  throughout  the  application  session.  The 
organization  of  the  menus  and  user  experience,  direct  or  indirect,  are  the  primary  context  driven  components 
that  evolve  as  system  utilization  progresses.  The  following  sections  provide  the  details  of  the  how  context  is 
employed  in  the  developmental  help  system. 

Appendix  E  provides  a  program  listing  of  TAE+  Help.  It  has  been  developed  using  a  special-purpose 
grammar,  interpreter  and  parser  created  by  D.  Masked  [MASKE  92].  Page  2  of  Appendix  E  provides  an 
example  describing  the  structure  of  the  state-based  grammar.  Appendix  F  provides  this  grammar  in  Backus- 
Naur  Form  (BNF).  In  general,  the  format  is  as  follows:  in  the  program  listing  each  code  segment  defines  *he 
state  being  specified,  the  action(s)  that  result  upon  occurrence  of  the  state  and  (he  catalysts  that  cause  a 
transition  and  associated  actions  that  result  from  invocation  of  the  catalyst. 

1.  Using  System-Based  Context 
a.  Menu  Access  Mechanism 

The  application  mode  being  employed  by  the  user  is  used  as  a  partitioning  mechanism  to 
tailor  menu  access  points,  providing  the  menu  page  to  the  user  that  contains  the  topic  titles  associated  with 
the  application  mode  in  use.  For  example,  if  the  current  WorkBench  Mode  is  Define  Connections,  it  is 
probable  that  the  user  is  searching  for  Panel-related  help.  Therefore,  the  menu  page  that  should  be  provided 
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first  should  be  the  page  that  contains  the  Panel-related  topic  titles.  Conversely,  if  the  current  WorkBench 
Mode  is  Set  Item  Default,  it  is  probable  that  the  user  is  searching  for  Item-related  help.  The  page  that  contain 
the  Item  titles  should  be  presented  first. 


b.  Menu  Transition  Mechanisms 

The  underlying  premise  of  the  menu/submenu  transition  is  that  presenting  topics  on  the  new 
menu  page  that  are  most-like  the  topics  on  the  page  that  was  left,  helps  the  user  maintain  the  mental  context 
of  problem  request  and  directly  presents  “most-probable"  topics  for  further  selection.  In  TAE+  Help  this 
occurs  in  both  main  menus  (Subwindow,  Task-oriented  and  Function-oriented  Menus)  and  submenus  (within 
the  Sub  window  Menu  structure)  to  main  menus. 

Code  excerpts  from  Appendix  E  are  provided  in  Figure  1  below  to  demonstrate  the  menu-to- 
menu  transition  process.  (An  explanation  of  the  grammar  is  detailed  on  page  2  of  Appendix  E.)  The  following 
code  segments  are  from  states  st_l_3_300  and  st_l_2_150.  While  in  state  st_l_3_300,  page  2  of  the 
function-oriented  menu  structure,  if  the  user  clicks  the  left  mouse  button  (click-left),  control  transfers  to  state 
st_l_2_150,  the  subwindow  page  containing  topic  titles  most-similar-to  those  found  on  the  st_l_3_300  page. 
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(st_l_3_300, 

((0,  clear), 

(0,  write,”  16.  Exiting  from  a  resource  file  23.  Item 

17.  with  save  24.  Aligning  multiple  items 

18.  without  save  25.  Creating 

19.  Exiting  from  T AE+  26.  Data  constraints/null  value 

20.  Generating  source  code  27.  Data  Driven  Objects  (DDOs) 

21.  Single/multi  file  generation  28.  Default  value 

22.  Including  resource  file  w/i  29.  Deleting  item 

another  resource  file  30.  Duplicating  item(s) 

{8,  write.  “Left-Middle-Right  mouse  buttons  provide  subwindow,  function-  and  task-oriented 
topic  lists  respectively."), 

(9,  input,  mouse&key)), 

(extraneous  code  removed  here...) 

((click-left,  st_l_2_l 50),  /*left  button  calls  for  sub-w  list*/ 

(click-middle,  st_l_3_l),  /*middle  button  calls  for  function  list*/ 

(click-right,  st_l_4_300),  /*right  button  calls  for  task  list*/ 

(extraneous  code  removed  here..  .) 
st_l_3_150)) 


(st_l_2_  1 50, 

((0,  clear), 

(0,  write,  “8.  PANEL  12.  ITEM 

9.  Panel  Specification  13.  Item  Specification 

10.  Panel  Details  14.  Item  Constraints 

11.  Dimension  Specification  15.  String  type  constraints 

16.  Integer  type  constraints 

17.  Real  type  constraints 

18.  Dimension  Specification 

19.  Presentation  Details 

(extraneous  code  removed  here...) 

(Enter  topic  number,  ‘N’  for  next  subwindow  page  or  ‘P’  for  previous  subwindow  page)”), 
(“n”l”N”,  st_l_2_200), 

(“P'Tp”,  st_l_2_l), 

(extraneous  code  removed  here...) 
st_l_2_375)) 


Figure  1.  Menu-to-menu  Transition  Process  Example 


2.  Using  User-Based  Context 

a.  Setting  and  Modifying  User’s  Experience  Level 

The  initial  setting  of  the  experience  level  is  derived  during  the  system  entry  from  question/ 
responses  geared  to  provide  clear  separation  points  between  the  experience  levels.  Subsequent  application  use 
modifies  the  initial  setting  based  on  help  system  access  requests.  TAE+  Help  supports  three  experience  levels 
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but  any  number  of  distinguishable  levels  can  be  supported.  The  code  segment  provided  in  Figure  2  sets  the 
experience  level  to  Knowledgeable.  State  st_l_l_4  queries  the  user  regarding  his  experience  with  the 
application.  If  the  user  has  had  experience  with  the  more  advance  functions,  the  user’s  skill  level  is  assessed 
to  be  Knowledgeable  and  control  transitions  to  st_l_l_300  to  accomplish  the  actual  setting.  In  state 
st_l_l_300.  after  clearing  the  screen,  previous  settings  (if  any)  are  nullified  by  the  retract  action.  A  message 
is  provided  to  notify  the  user  of  the  experience  setting  and  the  level  is  established  by  the  assert  action  prior 
to  transiting  to  the  next  state  (See  Appendix  E,  states  st_l_l_100,  st_l_l_200  and  st_l_l_300  for  the  novice, 
experienced  and  knowledgeble  setting  mechanisms,  respectively,  and  st_l_4_3  -  st_l_4_l  1  and  st_l_4_23  - 
st_l_4_47  for  modification  mechanisms). 


(st_I_l_4, 

(0,  write,  “Have  you  used  either  the  TAE+  Command  Language  (TCL)  to  update  objects  or 
detail  TAE+  generated  source  program  event  stubs?  (Please  enter  Y  or  N)”). 

(9,  input,  keyboard)), 

((15  seconds  &  (past  st_l_l_4  wait),  st_l_l_25), 

(15  seconds,  (assert,  wait),  st_l_l_4), 

(“YES’T’YesT’yeS’TYT’y”,  st_l_l_300),  /"set  experienced  level  to  Knowledgeable*/ 
(“NOT’NoTno’TNT’n”,  st_l_l_5), 
st_l_l_4))  /"unexpected  ans*/ 


(st_l_l_300, 

((0,  clear), 

(0,  retract,  st_l_l_100,  novice^user),  (0,  retract,  st_l_l_200,  exper_user).  (0,  retract, 
st_l_l_300,  knowl_user), 

(0,  write,  “...experience  level  set  to  KNOWLEDGEABLE...”), 

(6,  write,  “please  click  the  mouse...”)), 

/"  from  1_4_47  to  1_4_49  upgrade  exper  level  from  exper_user  to  knowl_user*/ 
(((past  st_l_4_47  active),  (assert,  knowl_user),  st_l_4_47), 

((past  st_l_4_48  active),  (assert,  knowl_user),  st_l_4_48), 

((past  st_l_4_49  active),  (assert,  knowl_user),  st_l_4_49), 

/*  No  active  states  during  the  initial  setup  -  falls  thru  to  here  */ 

(assert,  knowl_user),  st_l_l_6)) 

Figure  2.  Initial  Experience  Level  Setting  Example 


The  code  segment  provided  in  Figure  3  below  is  excerpted  from  state  st_l_4_5  to  demon¬ 
strate  the  mechanism  used  to  downgrade  experience  levels  when  topic  selection  indicates  an  inappropriately 
high  experience  leve  setting.  A  knowledgeable  user  is  not  expected  to  require  assistance  on  fundamental 
topics  like  opening  the  resource  file.  When  this  topic  is  selected  and  the  experience  level  of  the  user  is 
Knowledgeable,  an  active  flag  is  set  and  control  passes  to  state  st_l_l_200  ((past  st_l_l_300  knowl_user). 
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(assert,  active),  st_l_l_200).  State  st_l_l_200  resets  (downgrades)  the  experience  level  to  Experienced. 
When  st_l_l_200  concludes  its  action,  it  looks  for  an  active  flag.  Finding  state  st_l_4_6  active,  control 
returns.  Now.  redesignated  as  an  experienced  user,  the  requested  topic  will  be  presented  to  the  user  ((past 
st_l_l_200  exper_user),  (assert,  shown),  st_l_3_61). 


(st_l_4_5,  ((0,  clear),  (0,  retract,  st_l_4_5,  active),  (6,  write,  “please  click  the  mouse...”)), 
(((past  st_l_l_300  knowl_user),  (assert  active),  st_l_l_200), 

/•Knowledgeable  shouldn't  be  asking  this  question*/ 
((past  st_l_l_200  exper_user),  (assert  shown),  st_l_3_61). 

/*Non-novice  sees  specific  info  directly*/ 

(((past  st_l_l_100  novice_user)  &  (past  st_l_3_60  shown)),  (assert,  shown),  st_l_3_61), 

/•Novice  user  shown  genl  info,  then  returned  to*/ 
/•show  specific  info  OR  novice  saw  on  previous  req*/ 
((past  st_l_l_100  novice_user),  (assert,  active),  st_l_3_60)))  /*Novice  needs  to  see  genl 
info*/ 


Figure  3.  Modifying  the  Initial  Experience  Level  Setting  Example 


b.  Using  Experience  in  Access  and  Presentation  Decisions 

(1)  Experience  level.  Experience  levels  are  used  in  decisions  regarding  how  much 
information  to  present  to  the  user  and  the  manna  of  the  presentation.  In  TAE+  Help,  the  initial  experience 
level  setting  is  derived  from  past  experience  that  the  user  brings  to  the  use  setting.  The  initial  setting  is  then 
updated  throughout  the  session  by  tracking  what  has  been  shown  to  the  user  prior  to  this  point  and  what  topic 
is  being  currently  being  requested  by  the  user.  Figure  4  depicts  the  help  system  assessment  and  access 
process.  Upon  receipt  of  a  request,  TAE+  Help  reviews  the  user’s  experience  level  in  light  of  the  request  and 
a  determination  is  made  as  to  whether  the  current  experience  level  setting  is  appropriate.  The  existing 
experience  level  may  be  up-  or  downgraded  by  the  system  based  on  the  user’s  topic  selection.  After  the 
assessment,  the  experience  level  is  then  used  to  determine  what  help  text  should  be  presented  to  the  user. 
Novices  are  shown  both  the  general  and  specific  topics’  help  scripts  if  the  general  information  has  not  been 
shown  prior  to  the  request  being  addressed.  For  knowledgeable,  experienced  or  novice  users  that  have  been 
shown  the  general  topic  help  prior  to  the  current  request,  presentation  moves  directly  to  show  the  specific  text 
script  (See  Appendix  E,  st_l_4_38  and  st_  1  _3_23/st_ l _3_34). 

(2)  Using  pre-existing  knowledge.  The  typical  user  can  be  expected  to  have  some  other 
computer  experience  and  may  even  have  some  amount  of  experience  with  the  target  application  that  may  be 
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similar  to  operations  being  documented  in  the  help  system.  If  two  operations  are  known  by  the  developer  to 
be  similar  in  some  way.  the  help  text  may  be  written  to  relate  the  two  operations.  In  this  case,  the  user  would 
be  queried  as  to  if  they  have  had  any  experience  with  the  other  topic.  If  so,  the  new  topic  is  presented  using 
the  somewhat  familiar  terminology.  Otherwise,  no  assumptions  are  made  and  the  topic  is  presented  in  the 
more  typical  fashion.  For  example,  in  TAE+  Help,  when  a  user  requests  help  for  Data  Driven  Objects 
(DDOs),  the  user  is  queried  as  to  whether  they  have  any  experience  with  other  types  of  dynamic  items, 
specifically.  Selection  Objects.  If  the  answer  is  affirmative,  the  requested  DDO  help  text  is  explained  in 
terminology  that  leverages  the  existing  Selection  Object  knowledge  and  thereby  reduces  the  amount  of  “new” 
information  the  user  has  to  contend  with.  If  the  answer  is  negative,  no  assumptions  are  made  and  the  DDO 
topic  is  explained  fully  (See  Appendix  E,  st_l_4_300,  st_l_4_28,  and  st_l_4_28_2  for  the  implementation 
of  this  capability). 

D.  THE  TAE+  HELP  SYSTEM 

In  TAE+  Help,  a  three-tiered  menu  hierarchy  system  leverages  and  updates  the  gathered  contextual 
information  to  facilitate  the  help  system  access  process.  The  first  menu  tier  is  the  Subwindow  Menu 
component  Its  topic  list  consists  of  a  collection  of  the  titles  of  the  TAE+  subwindows  that  the  user  sees  while 
accomplishing  the  typical  application  development.  It  is  intended  to  support  queries  related  directly  to  a 
known  subwindow.  Upon  selection  of  a  title  by  the  user,  submenus  are  generated  and  presented  to  the  user  to 
facilitate  more  precise  determination  of  the  user’s  question  prior  to  selection  of  the  topic  text  component 
assessed  to  be  most  applicable.  Once  the  topic  is  pinpointed,  system  control  transitions  to  the  function- 
oriented  program  component  and  the  help  text  is  presented  (See  Appendix  E,  states  st_l_2_l.  st_l_2_150 
and  st_l_2_200  for  the  full  Subwindow  Menu  implementation.  Excerpts  are  provided  below  in  Figure  5.). 

The  Task-oriented  menu  component,  the  second  tier,  provides  a  collection  of  topics,  ordered  by  task 
name.  The  ordering  of  titles  within  this  menu  is  based  on  the  order  the  user  would  encounter/accomplish  tasks 
when  progressing  through  the  typical  interface  development.  It  is  intended  to  support  users  needs  regarding 
“Where  am  I?"  and  “What’s  next?”  in  the  development  process  and  possibly  “What  can  I  do?”.  Within  this 
component,  user  experience  classification  is  checked  to  reconcile  the  request  with  the  recorded  experience 
level  and  any  experience  level  adjustments  are  made  as  deemed  appropriate.  Additionally,  decisions  on  the 
need  to  provide  broad  topic  information  text  in  addition  to  the  requested  specific  topic  are  made  based  on  the 
experience  level  of  the  user  and  the  history  of  help  received  prior  to  the  current  request  If  the  user  is  a  Novice 
and  is  asking  for  specific  topic  information,  but  has  not  yet  seen  the  general  topic  help  text;  the  current  state 
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(st_l_2_l, 

((0,  clear), 

(0,  write,  “1.  Sub-Window  List 

2.  TAE+  WorkBench:  Resource  Filename 

3.  FILE 

4.  New  File 

5.  Open  File 

6.  Include  File 

7.  Save  As  File 

8.  PANEL/ITEM/OTHER  COMMANDS 
(extraneous  code  removed  here...) 

(“8’T’N”i”n”l”Eight’T'eight”l"EIGHT”,  st_l_2_150), 
st_l_2_225)) 


(st_i_2_150, 

((0.  clear), 

(0,  write,  “8.  PANEL  12.  ITEM 

9.  Panel  Specification  13.  Item  Specification 

10.  Panel  Details  14.  Item  Constraints 

1 1.  Dimension  Specification  IS.  String  type  constraints 

16.  Integer  type  constraints 

17.  Real  type  constraints 

18.  Dimension  Specification 

19.  Presentation  Details 

(extraneous  code  removed  here...) 

(Enter  topic  number,  ‘N’  for  next  subwindow  page  or  ‘P*  for  previous  subwindow  page)"), 
(“n’T’N”,  st_l_2_200), 

(“P’T’p”,  st_l_2_l), 

(extraneous  code  removed  here...) 
st_l_2_375)) 


(st_l_2_200, 

((0,  clear), 

(0.  write,  “20.  DUPLICATE  24.  AUXILIARY 

21.  Group  Modification  25.  Specify  Initial  Panels 

22.  ALIGNMENT  26.  Application  Generation 

23.  Current  Selection  Alignment  27.  Terminal 

28.  WB  Preferences 

29.  Connections  Specification 

(Enter  topic  number  or  ‘P’  for  previous  subwindow  page)”), 

(extraneous  code  removed  here...) 

Figure  5.  Subwindow  Menu  Implementation  Code  Segments 
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is  flagged  as  active  and  system  control  transitions  to  the  function-oriented  program  component  where  the 
general  topic  is  presented.  Then  control  returns  to  the  active  state  and  the  specific  topic  request  is  processed 
(See  Appendix  E,  states  st_l_4_13,  st_l_3_43  and  st_l_3_44  for  an  example  of  this  implementation  in  TAE+ 
Help). 

Finally,  the  Function-oriented  Menu  component  provides  an  composite  listing  of  topics,  ordered 
alphabetically.  This  list  includes  all  of  the  Task-oriented  Menu  topic  titles  plus  any  other  topics  that  can  be 
expected  to  arise  from  previous  computer  experience  (e.g.,  use  of  word  processing  packages,  other 
development  or  graphic  tools,  etc.).  This  topic  list  provides  the  “fmest-grain”  level  of  topic  selection  and  is 
intended  to  support  “How  do  I?”  queries,  enabling  the  user  to  quickly  find  the  means  of  accomplishing  a 
known  action/capability.  The  function-oriented  program  listing  section  is  where  all  help  texts  are  coded. 
Subwindow  and  task-oriented  menus  pinpoint  the  topic  title  and  access  the  applicable  function-oriented  topic 
script  for  the  actual  help  text  (transparent  to  user). 

Within  each  help  system  window,  the  user  is  given  access  to  left-,  middle-  and  right-mouse-button 
clicks  to  move  from  one  menu  structure  to  another.  Menu  and  submenu  page  linkages  transit  to  similar-topic 
pages  within  the  other  menu  structures.  This  reduces  the  user’s  cognitive  load  thereby  assisting  them  in 
focusing  on  maintaining  the  working  context  vice  worrying  about  the  mechanics  of  the  menu  system.  For 
example,  the  transition  out  the  subwindow  menu  page  that  has  TAE+  Panel-related  tides  on  it  results  in 
accessing  the  task-oriented  menu  page  with  Panel  titles  on  it.  A  left  click  invokes  the  Subwindow  Menu,  a 
middle  click  the  Task-oriented  Menu  and  a  right  click  the  Function-oriented  Menu. 

E,  CONCLUSION 

This  chapter  has  presented  a  description  of  the  development  process  used  to  identify,  gather  and  employ 
context  in  the  access  and  presentation  strategies  of  a  dynamic,  context-driven  help  system.  Additionally,  the 
chapter  provides  an  overview  of  TAE+  Help,  a  help  system  prototype  developed  to  demonstrate  the 
advantages  afforded  by  integrating  user  and  system  elements  into  the  help  system  structure.  The  last  chapter 
summarizes  the  utilization  of  context  in  the  prototype  and  discusses  directions  for  further  research. 
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IV.  CONCLUSIONS  AND  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 


The  purpose  of  this  thesis  is  to  develop  a  method  of  identifying,  capturing  and  employing  elements  of 
the  user's  working  context  to  create  a  dynamic,  context-driven  online  help  system.  This  chapter  provides  a 
description  of  the  help  system  development  process,  a  summary  of  the  contributions  and  discusses 
recommendations  for  future  research. 

A.  METHODOLOGY  OF  PROTOTYPING  A  HELP  SYSTEM 

A  help  system  prototype  has  been  developed  to  demonstrate  the  improved  help  system  effectiveness 
afforded  by  integrating  and  employing  system-  and  user-based  elements  in  the  help  text  retrieval  process.  The 
initial  effort  involved  defining  the  user  model  as  well  as  a  strategy  for  revising  the  initial  user  model  as  the 
user’s  experience  evolves  or  as  help  title  selection  indicates  is  warranted.  The  development  of  the  help  system 
decision  structure  occurs  next  and  relies  heavily  upon  the  dynamics  of  both  the  user  and  the  situation. 

The  advantage  of  basing  the  help  system's  user  model  on  both  experience  and  situation  include  an 
ability  for  the  help  system  to  adapt  in  two  dimensions.  The  help  system  mechanism  evolves  as  the  user’s 
experience  grows,  changing  from  prefacing  specific  requests  with  general,  framing  assistance  to  directly 
provide  the  requested  assistance.  The  mechanism  could  also  be  used  to  support  further  tailoring  of  the 
presentation  to  provide  additional,  specially  formatted  information  for  the  more  advanced  user.  The  help 
system  mechanism  also  evolves  based  on  the  application  mode  being  applied,  by  tailoring  the  menu  structures 
to  present  and  access  the  topic  titles  most  appropriate  to  the  current  work  situation. 

1.  The  Initial  User  Model 

The  initial  user  model  was  evolved  based  on  two  components:  user  experience  and  application 
mode  being  applied.  When  the  help  system  is  entered,  the  user  is  queried  on  the  experience  they  have  using 
the  application.  The  questions  are  formulated  to  provide  a  partitioning  mechanism  that  affords  a  means  of 
categorizing  each  user  into  a  single  experience  level,  for  example,  novice,  intermediate,  experienced,  etc. 
Each  user  is  rated  upon  entrance  into  the  help  system  and  that  rating  serves  as  the  experience  level  variable 
in  the  help  system  access  process  until  it  is  changed  by  further  help  system  use.  The  second  component  is  the 
application  mode  being  applied  by  the  user.  The  mode  provides  an  additional  source  of  scooping  information 
that  is  then  used  to  improve  the  relevancy  of  the  information  that  is  provided  to  the  user.  The  user  is  queried 
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as  to  whether  the  application  mode  has  changed  if  the  help  title  being  selected  indicates  that  the  mode  has  or 
should  be  changed.  These  are  the  elements  that  are  updated  periodically  throughout  the  session  and  provide 
the  mechanism  by  which  the  interface  adapts. 

2.  Strategy  for  Using  and  Revising  the  User  Model 

The  user  experience  level  influences  the  order  and  presentation  of  the  help  text.  If  the  user  is 
requesting  assistance  on  a  specific  topic  and  is  an  inexperienced  user,  the  help  command  system  history  is 
consulted  to  determine  what  information  has  been  presented  to  the  user  during  the  session.  If  the  user  has  not 
been  presented  with  the  general  topic,  it  is  assumed  that  the  user  would  benefit  from  the  additional 
background  information  and  results  in  th'  resent,  on  of  the  general  topic  followed  by  the  specific  topic  text 
The  experience  level  is  up-  or  downgrade  iroughout  the  session  by  monitoring  and  assessing  the  help  topic 
title  selections  in  conjunction  with  the  assigned  experience  level.  For  example:  if  the  user  is  assessed  to  be 
an  inexperienced  user  upon  system  initialization  they  be  provided  with  general  topic  information  before  the 
specific,  then  once  they  complete  the  tasks  up  to  a  pre-determined  point  in  the  application,  the  experience 
level  automatically  adjusts  to  reclassify  them  as  an  intermediate  user.  Downgrading  occurs  if  the  topic 
selections  being  made  indicate  that  the  experience  rating  was  set  inappropriately  high. 

The  advantage  of  the  dynamic  structure  over  static  help  system  structures  is  the  ability  of  the  user 
model  to  adapt  based  on  the  user’s  experience.  By  revising  the  user  model,  the  help  system  is  able  to  adapt 
to  the  user,  not  just  within  the  session  but  also  throughout  the  lifetime  that  the  application  is  used  by  the  user. 
The  first  time  the  application  is  used,  the  user  will  probably  be  assessed  as  a  novice  user.  The  experience  level 
assessment  mechanism  is  flexible  enough  to  adjust  the  user's  experience  level  during  the  session  as  the  user 
becomes  more  knowledgeable  (or  is  deemed  to  be  less  knowledgeable  than  assessed).  Additionally,  upon 
subsequent  entries  into  the  application  previous  experience  can  then  be  factored  into  the  assessment  and  may 
result  in  a  more  advanced  experience  level  setting.  Static  structures  are  invariant  They  provide  the  same 
response  to  the  assistance  requests,  with  no  influence  exerted  by  the  user’s  experience. 

3.  Developing  the  Help  Structure 

The  development  of  the  help  structure  is  accomplished  by  first  modeling  the  system  behavior 
using  state-transition  diagrams  (STDs)  and  from  that  identifying  the  types  of  help  questions  and  the  context 
indicators  that  are  evident  at  each  state.  The  questions  and  context  indicators  become  the  foundation  from 
which  the  menu  structures  and  help  text  presentations  are  formed.  This  is  advantageous  as  it  facilitates  an 
incremental  and  more  comprehensive  development  effort.  The  tables  are  built  through  examining  each  state. 
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The  resulting  tables  are  used  directly  to  build  the  three  menu  structures  and  form  the  text  presentation  decision 
structure.  The  subwindow  and  task-oriented  menu  structures  fall  out  of  the  association  of  topic  titles  to 
application  states  that  the  tables  portray.  The  function-oriented  menu  is  merely  a  superset  of  all  of  the 
subwindow  and  task-oriented  menu  titles  plus  any  additional  titles  that  may  result  from  pre-existing  computer 
or  other  application-use  experience. 

a.  Identify  the  Situation 

The  time  dependent  behavior  of  the  system  is  captured  by  recording  possible  states  that  occur 
in  the  system,  the  paths  used  to  reach  the  state,  the  possible  transitions  out  of  the  state  and  the  actions  resulting 
from  the  transition.  Youndan’s  STD  structure,  described  in  [YOURD  89],  is  used  to  depict  the  application's 
behavior. 

Once  the  STDs  are  complete,  each  state  is  assessed  in  isolation  to  note  and  record  help 
questions  that  are  prompted  by  the  state.  The  questions  are  organized  into  the  five  question-class  structure 
described  by  Sellen  and  Nicol  in  [SELLE  90]  and  the  resulting  table  is  used  to  cross-check  the  completeness 
of  the  state  assessment  The  advantage  to  this  approach  is  this  provides  a  tool  for  creating  a  help  system  that 
attempts  to  anticipate  all  of  the  assistance  needs  that  any  user,  from  the  novice  to  the  knowledgeable,  may 
have  while  using  the  system.  Focusing  on  each  state  individually  provides  the  developer  with  a  logical  way 
to  partition  the  system  and  facilitates  identifying  all  questions  that  arise  within  the  state.  The  resulting  table 
also  provides  a  way  of  identifying  the  different  perspectives  from  which  each  question  might  arise. 

b.  Identify  Relevant  Topics/Questions 

A  second  table  structure  is  developed  with  the  assistance  of  the  STDs  to  identify  and  record 
“observables”  such  as  window  tides,  visible  icons,  etc.,  specific  to  the  state  that  can  be  used  to  collect 
situation-specific  context  data.  Additionally,  as  the  states  are  reviewed,  questions  are  recorded  to  be  put  to 
the  users  in  situations  where  context  ambiguity  might  be  further  resolved.  These  observables  allow  the  help 
system  to  better  focus  the  access,  providing  information  that  is  more  relevant  and  specific  to  the  user’s 
situation. 


c.  Compose  the  User  Message 

The  third  phase  of  the  help  system  development  uses  all  of  the  previous  user  and  system 
mapping  effort  to  create  the  interface  itself.  Menu  and  submenu  structures  are  developed  from  the  five-class 
questions  and  the  context  observables  tables;  menu  ordering  and  transitions  fall  out  of  the  STDs  and  the  text 


29 


script  and  presentation  details  emerge  from  the  user  model  projections.  The  resulting  interface  provides  a  help 
system  that  adapts  to  the  user  throughout  the  session,  and  indeed  throughout  the  lifetime  use  of  the  application, 
by  capturing  and  recording  context-related  information  from  the  working  environment  and  employing  it  in  the 
help  system  access  process. 

B.  SUMMARY  OF  CONTRIBUTIONS 

A  dynamic,  context-based  help  system  uses  snapshot  representations  of  the  work  environment  situation 
and  the  user  to  create  a  help  system  architecture  that  evolves  throughout  the  session.  The  resulting  assistance 
system  uses  the  situational  elements  to  predict  the  topic  of  the  question  being  asked  thereby  1)  assisting  the  user 
in  forming  the  question  and  2)  improving  the  help  system  access  process.  This  results  in  selection  and 
presentation  of  help  text  which  is  more  relevant  and  specific  to  the  work  situation. 

Selected  topics  can  be  related  to  similar  topics,  whether  they  relate  directly  to  another  function  of  the 
application  or  relate  to  some  other  common  activity  (like  saving  a  file,  for  example).  When  this  is  possible,  the 
user  is  first  presented  with  a  question  asking  if  they  have  knowledge  of  the  related  activity.  If  so,  the  new  topic 
is  presented  to  the  user  using  terminology  to  relate  the  new  to  the  known  topic,  lessening  the  amount  of  new 
information  the  user  must  conceptualize. 

The  user  elements  are  used  to  tailor  the  response  to  the  specific  user  by  determining  the  sequence  and 
amount  of  help  assistance  that  should  be  provided.  Less  experienced  users  are  presented  general  assistance  as 
well  as  the  more  specific  text  to  improve  their  base  of  information  of  the  application’s  commands.  The  tailoring 
mechanism  can  also  be  used  to  modify  the  presentation  of  experienced  users  by  providing  additional  shortcut 
key  sequences/hints  for  more  efficient  usage.  Due  to  limitations  of  the  grammar  used  for  implementation,  this 
capability  has  not  been  provided  in  the  prototype. 

The  final  element  of  the  dynamic  structure  that  was  improved  is  the  menu  structure.  Three  topic  list 
structures  are  supported:  a  subwindow  menu  organized  by  application  subwindow  title,  a  task-based  menu 
organized  by  sequential  ordering  of  the  typical  tasks  used  and  a  function-based  menu  organized  alphabetically 
by  topic.  The  three-tiered  menu  organization  provides  several  mechanisms  for  the  user  to  chose  from  in 
mapping  the  question-to-be-asked  to  the  help  architecture.  The  subwindow  structure  provides  a  one-to-one 
direct  mapping  of  the  application  subwindow  to  the  help  system  menu.  The  task-based  list  provides  a  link 
between  the  task  being  attempted  as  well  as  indicates  the  next  logical  task  and  the  relative  progress  made  in 
completing  the  task  sequence.  Lastly,  the  function-based  list  provides  a  quick  access  mechanism  to  locate 
assistance  for  a  known  capability. 
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C.  RECOMMENDATIONS  FOR  FUTURE  RESEARCH 


This  thesis  concentrated  on  developing  a  methodology  for  identifying  and  employing  elements  of  the 
user's  context  to  improve  assistance  provided  hy  online  help  systems.  The  early  developmental  process  entails 
diagramming  and  examining  the  target  application’s  functionality  to  identify  the  context-framing  elements  of 
the  situation.  Done  manually,  this  is  a  tedious,  detail-laden  process.  A  automated  tool  is  needed  to  assist  the  user 
in  identifying  and  verifying  the  completeness  of  the  context-assessment  effort.  The  tool  could  verify  that  all 
state-transition  diagram  state  paths  have  been  investigated  and  that  all  classes  of  user-questions  have  been 
addressed. 

Another  piece  of  the  development  process  involves  identifying  questions  that  may  be  asked  of  the  user  i 
supplement  the  help-system-gathered  context  information.  The  current  system  configuration  accomplishes  the 
context  gathering  via  a  manual,  time-intensive  question-and-answer  dialogue  between  the  user  and  the  menu 
structures.  An  automated  context  sensor  mechanism,  and  indeed  a  theory  of  designing  sensors,  needs  to  be 
developed  to  collect  situational  data  electronically,  in  a  way  that  is  transparent  to  the  user. 

One  of  the  presentation  strategies  of  the  dynamic  help  system  structure  is  to  exploit  the  user’s  experience 
with  similar  tasks.  Adding  additional  strategies  provides  more  interface  flexibility,  such  as  presenting  related 
commands  or  keyboard  shortcuts  to  experienced  users,  but  it  is  difficult  to  add  to  an  existing  dynamic  help 
system  structure.  Changes  ripple  through  the  system  and  can  cause  both  unanticipated  and  undesireable 
changes.  The  current  manual  process  requires  the  developer  to  manually  trace  all  of  the  state-transition  paths 
for  affected  states  and  then  retrace  each  again  if  further  changes  are  added.  This  tracing  quickly  becomes 
unmanageable  as  the  system  functionality  grows.  An  automated  tool  to  display  and  manage  the  help  system 
structure  is  needed  to  provide  the  developer  with  a  pictorial  representation  of  all  of  the  affected  paths  and  states. 
Additionally,  a  methodology  is  needed  to  efficiently  add  or  change  strategies  or  other  elements  of  the  user  or 
system  models. 

A  strategy  is  needed  to  manage  or  better  exploit  the  knowledge  that  the  system  has  ana  acquires  about  the 
user.  An  assumption  is  made  that  once  the  user  has  been  shown  a  help  topic  text  they  understand  the  topic  and 
how  it  fits  into  the  framework  of  the  application.  A  mechanism  is  required  to  verify  the  user’s  understanding  of 
the  provided  assistance.  Additionally,  this  mechanism  should  feedback  information  to  the  sensor  structure  for 
use  in  monitoring  the  user  actions  and  assisting  in  subsequent  issues  like  whether  additional  background 
information  on  a  specific  command/action  is  necessary.  Finally,  the  issue  of  how  many  levels  of  experience  to 
design  into  the  help  system  structure  was  addressed  ad-hoc  in  this  thesis.  Additional  research,  to  provide  a  solid 
basis  for  this  decision,  would  be  useful. 
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APPENDIX  A 


TRANSPORTABLE  APPLICATIONS  ENVIRONMENT  PLUS  (TAE+) 

A.  INTRODUCTION 

Transportable  Applications  Environment  Plus  (TAE+)  is  a  portable  software  development  environment 
that  supports  rapid  building,  tailoring  and  management  of  graphic -oriented  user  interfaces.  It  uses  MITs 
XWindow  System  (Ver  1 1,  Rel  4)  and  the  Open  Software  Foundation’s  (OSFs)  Motif  Toolkit.  It  can  generate 
source  code  in  C,  C++,  Fortran  and  Ada  as  well  as  high  level  TAE  Command  Language  (TCL). 

B.  OVERVIEW 

This  section  provides  a  description  of  the  T  AE+  working  environment  and  one  of  its  major  components, 
the  TAE+  WorkBench,  thus  forming  a  conceptual  framework  within  which  this  thesis  it  to  be  read. 

1.  TAEnvironment 

TAEnvironment  is  an  encompassing  environment  that  manages  and  provides  access  to  the  TAE+ 
development  tools  via  an  icon  menu.  Components  include;  the  WorkBench;  taeidraw.  a  graphic  drawing  tool; 
windows  for  access  to  the  host  operating  system  and  FTP;  Code  Generator,  a  utility  program  that  generates 
source  code  from  the  TAE+  resource  file,  and  an  object  bank  and  demo  component  which  provide  interactive 
samples  and  implementation  of  a  variety  of  TAE+  objects.  This  thesis  applies  primarily  to  the  TAE+ 
WorkBench  and  its  utilization  by  the  developer  to  accomplish  the  fundamental  development  of  an  interface, 
to  wit,  the  visual  appearance,  the  user  interaction  mechanisms  and  the  intra-interface  linkages  and  actions. 

2.  TAE+  WorkBench 

The  TAE+  WorkBench  is  a  developmental  tool  that  supports  the  interactive  design  and  layout  of 
graphical  user  interfaces  [NASA  91],  There  are  two  main  elements  used  in  building  the  interface:  panels  and 
items.  Panels  are  the  windows  seen  by  the  application  user.  In  the  [context  -  need  correct  word  here]  of  TAE+ 
they  hold  a  collection  of  interactive  items.  Items  are  the  mechanisms  by  which  interaction  (input  and/or 
output)  between  the  user  and  the  application  is  accomplished.  Examples  of  items  include  buttons,  text  display 
boxes,  scroll  bars,  menus,  etc. 
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The  first  step  in  the  development  effort  is  to  create  the  visual  picture  of  what  the  user  sees  when 
using  the  application.  Specification  of  panels  and  items  occurs  while  the  TAE+  WoricBench  is  in  “Move/ 
Resize/Edit"  mode.  Figure  1  provides  a  sample  electronic  day  planner  page  to  support  this  explanation. 

a.  Create  Panels 

The  developer  first  creates  a  panel  and  specifies  the  desired  physical  characteristics  of  the 
panel.  Typically,  the  panel  size  and  screen  location  are  defined  as  well  as  the  desired  font  and  screen  color. 

b.  Create  Items 

Next,  the  developer  creates  and  specifies  the  items  which  will  be  visible  on  the  panel.  For 
our  day  planner  page,  appropriate  items  might  be:  a  calendar  month  display  area,  buttons  to  provide  QUIT, 
and  ENTER  NEW,  MODIFY,  DELETE  of  existing  appointment  information  and  Text  display/label  items 
(see  Figure  1).  Creating  and  specifying  each  of  these  types  of  itemsis  address  individually  below. 

To  create  the  calendar  month  display  area,  first  create  a  new  item,  specifying  an  unique  item 
name  and  defining  the  panel  it  is  to  be  placed  on.  This  type  of  item  has  a  data  type  of  “String”  (chosen  from 
String,  Integer  or  Real),  and  is  of  “Presentation  Category:  Text”  and  “Presentation  Type:  Text  Display". 
Additionally,  a  border  width  of  3  and  a  shadow  thickness  of  2  has  been  chosen  by  the  developer.  The 
developer  has  the  option  to  restrict  the  data  to  a  specified  string  length  and  to  specify  the  size  (width  and 
height)  of  the  text  display  area  and  the  location  it  is  to  appear  on  the  panel.  To  adjust  the  location,  the 
developer  merely  clicks  on  the  item  to  "select"  it  and,  holding  the  mouse  button  down,  drags  it  to  the  preferred 
location.  The  mechanics  of  generating  the  calendar  and  linking  the  text  will  be  described  below.  The  initial 
step  is  to  get  the  visual  component  defined.  The  second  type  of  item  required  in  the  day  planner  is  a  button. 
Again,  the  item  must  be  uniquely  named  and  associated  with  the  parent  panel.  Buttons  are  of  data  type 
“String,  Presentation  Category:  Selection”  and  “Presentation  Type:  Push  Button”.  The  item  title  provides  the 
button  label,  for  example,  the  title  of  the  QUIT  button  is  "QUIT".  This  button  label  can  be  left  or  right 
justified  or  centered  on  the  button  via  the  "Specify  Details"  operation.  The  third  type  of  item,  text  display  and 
label  items  are  of  “String”,  “Presentation  Category:  Text"  and  "Presentation  Type:  Keyin’’.  The  item  title 
labels  each  with  the  appropriate  hour  (0800, 0900,  etc.).  The  "Set  Details"  operation  allows  the  developer  to 
restrict  data  entry  to  50  characters  to  prevent  the  input  from  overflowing  the  provided  space.  In  other 
applications  the  "Set  Constraints"  operation  can  be  used  to  restrict  the  user's  data  entry.  For  example,  when 
entering  a  new  appointment  the  user  would  be  queried  as  to  the  time  slot  to  change.  At  that  point  a  data  entry 
check  would  be  done  to  ensure  the  reply  was  one  of  0800, 0900. 1000...  1600.  etc. 
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c.  Defining  Item  Connections 

Once  the  visual  layout  of  the  panels  and  items  is  specified  the  developer  must  define  the  item 
connections.  The  WorkBench  mode  is  changed  to  “Define  Connections”.  As  each  object  is  selected  (by 
clicking  on  it),  a  “Connection  Specification”  window  appears  allowing  the  developer  to  define  the  disposition 
of  the  current  panel  and  to  identify  the  desired  subsequent  panel.  Choices  of  current  panel  state  after 
connection  to  the  next  panel  are:  “Preferred”  (it  remains  the  active  window),  “iconic”  (the  window  becomes 
an  icon),  “deleted”,  “invisible"  or  “no  change”.  Information  pertinent  to  the  "next"  panel  includes  "panel 
name”,  and  “panel  state”:  preferred,  iconic,  deleted,  etc.  Additionally,  there  is  an  area  "TCL  command"  to 
enter  a  TAE+  Command  Language  string  that  would  be  executed  upon  connection  to  a  subsequent  panel. 

d.  Generating  Source  Code 

When  the  interface  design  is  complete,  the  developer  generates  source  code  using  the 
automatic  generation  utility.  Languages  supported  are  Ada.  C,  C++,  FORTRAN  and  high  level  TAE 
Command  Language(TCL).  Each  item  and  the  actions  resulting  from  the  execution  of  the  item  are  considered 
an  event.  The  Code  Generator  creates  event  "stubs"  that  must  subsequently  be  fleshed  out  by  the  developer 
to  fully  define  the  desired  functionality. 
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APPENDIX  B 


TAE+  STATE  TRANSITION  DIAGRAMS  (STDs) 


Yourdon  in  (YOURD  89]  describes  the  state-transition  diagram  notation  used  in  this  thesis.  Each  rect¬ 
angular  box  represents  a  state  that  a  system  can  be  in.  The  arrows  indicate  state  changes  and  each  is  anno¬ 
tated  with  a  two  part  label.  The  condition  describes  the  catalyst  that  causes  the  state  to  change  and  the  action 
describes  the  things  that  happen  as  a  result  of  the  transition  from  the  former  state  to  the  subsequent  one.  Fig¬ 
ure  1  illustrates  these  concepts. 

STD  development  steps: 

1.  identify  all  the  possible  states  OR  identify  the  initial  state 

2.  identify  the  transactions/conditions  (catalyst  causing  change  of  state) 

3.  identify  the  actions  (what  happens/results  Grom  chg  of  state) 


STATE  1 

1 

Condition 

Action 

r 

STATE  2 

FIGURE  1:  STD  Constructs  [YOURD  89]] 
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STATE  TRANSITION  DIAGRAMS  FOR  TAE+ 


**  This  is  a  special  case  of  State  0  in  which  the  TAE+  WorkBench  component  is  activated 
directly  versus  via  the  icon  menu.  Rather  than  addressing  it  separately  the  minor  differences 
minor  differenceswill  be  noted  in  depictions  of  State  0. 
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APPENDIX  C 


TAE+  STATE-QUERIES-TABLE 


This  table  provides  a  listing,  catagorized  by  class  of  question,  of  the  questions  that  arise  at  each  state. 
Sellen  and  Nicol  in  [SELLE  90]  cite  an  addtional  type  of  question  class.  Descriptive.  These  types  of  questions 
are  adequately  addressed  by  the  existing  TAE+  application  and  therefore  are  not  address  here. 
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APPENDIX  D 


TAE+  CONTEXT-CLUES-TABLE 


This  table  provides  a  listing,  of  the  observable  elements  of  each  state  and  the  questions  that  may  be 
asked  of  the  user  to  better  determine  the  desired  topic. 
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1  3.4.2  Application  Generation  Sub-W  Request  lor  information  re  source  language,  lile  structure, 

Waiting  for  (from  Code  Generation  selection)  diagnostic  messages,  event  handlers 

Generation 

Details 


APPENDIX  E 


TAE+  HELP  SYSTEM  PROGRAM  LISTING 


This  appendix  provides  the  program  script  for  TAE+  Help.  Figure  1  belo'v,  provides 
a  pictorial  representation  of  the  system  setup  process,  establishing  the  initial  user 
experience  level  and  menu  structure  choice. 


•Menu  access  point  dependent  upon  current 
TAE+  mode 
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The  general  format  of  the  program  listing  is  to  declare  the  state  being  addressed,  specify  the 
actions  that  occur  during  each  instance  of  the  state  and  detail  all  the  possible  transitions  out  of  the  state  and 


the  resulting  actions  of  each  transition.  For  example: 

(st_l_l_l, 

((0,  clear), 

(0.  write,  “  Welcome  to  the  TAE+  Help  System..  Have  you  used  TAE+  in  the  past?  (Please 
enter  Y  or  N)”, 

(9.  input,  keyboard)), 

((15  seconds  &  (past  st_l_l_l  wait),  ), 

(15  seconds,  (assert,  wait),  st_l_l_l), 

(“YEST’YesT’yes’T’YT’y”,  TAE_user),  st_l_l_4), 

("NO’T’No'Tno’TN’T’n”,  (assert,  non_TAE_user),  st_l_l_2), 
st_l_l_l))  /*unexpected  ans*/ 


The  above  code  defines  state  st_l_l_l.  The  first  action  (0.  clear)  clears  the  screen,  the  sec¬ 
ond  (0,  write,  “  Welcome  to  the  TAE+  Help  System...”)  writes  a  message  to  the  screen  and  the  final  action 
(9,  input,  keyboard)  enables  the  keyboard  to  receive  input  from  the  user.  The  next  two  lines  provide  30  sec¬ 
onds,  in  two  15  second  increments,  for  the  user  to  respond  to  the  question.  If  the  user  does  not  answer 
within  the  alloted  30  seconds,  control  transfers  to  state  st_l_l_20  which  informs  the  user  that  an  assumption 
has  been  made  regarding  his  experience  with  using  TAE+.  If  the  user  provides  a  “yes”  or  “no”  answer,  con¬ 
trol  transfers  to  subsequent  state  st_l„l_4  or  st_l_l_2  respectively:  any  other  answer  results  in  control  loop¬ 
ing  back  into  the  state  st_l_l_l. 
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("NOTNoTnoTNTn",  st_l_l_5), 
st_l_l_4))  /‘unexpected  ans*/ 
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/*  for  Move/Resi/e/Edil  mode  */ 


((0,  write,  "  Is  your  help  request  related  to  a  particular  TAE+  sub-window?  (Please  enter  Y  or  N)  ”), 
(9,  input,  keyboard)). 
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((0,  write, "  Is  your  help  request  related  to  a  particular  TAE+  sub-window?  (Please  enter  Y  or  N) "), 
(9,  input,  keyboard)). 
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t*  Collects  application  mode  in  use  when  mode  change  is  detected  during  use  session 
/*  See  st_l_l_6  and  st_l_l_8  for  initial  setting  mechanisms*/ 
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(Please  enter  1, 2, 3, 4  or  5)"), 


(st_l_l_45, 

((0,  write, "  You  have  not  replied  or  have  entered  an  invalid  ttnswer.  It  is  assumed  you  are  in  Move/Resize/Edit  inode.”),  (0,  pause,  5)), 
st_l_2_l)  /‘User  is  experienced,  thus  presented  w/  function-oriented  topic  list*/ 


(st_I_l_50, 

((0,  write, "  You  have  not  replied  or  have  entered  a  default  answer."),  (0,  pause,  5)), 
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(0,  clear), 

(assert,  shown),  st_l_3_23) 
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(st_l_2_5Q, 

((0,  clear), 

(0,  write.  ”  Select  topic  number: 

1.  Frame 

2.  Titlebar 


3.  Panel  Stale 

4.  Panel  Dimensions  (...subsequent  menu...' 

5.  Panel  Help  file 

6.  Panel  icon  file 
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(st_l_2_250, 

((0,  write,  "  Selected  option  not  yet  implemented."), 

(6,  write,  "Reluming  you  to  your  originating  menu  page... 
(0,  pause,  5)), 


(st_l_2_275, 

((0,  write, "  Selected  option  not  yet  implemented."), 

(6,  write,  "Returning  you  to  your  originating  menu  page.. 
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(st_l_3_l, 

((0, clear), 

(0,  write, "  l.  Function-oriented  Topic  List  9.  Defaults 


2.  Aligning  objects  10.  Setting  default  panel 

3.  Changing  alignment  delta  11.  Setting  item  default  value 

4.  Specifying  alignment  params  12.  Defining  panel  connections 

5.  Applying  a  command/action  13.  Quit  command 

6.  Canceling  a  command/action  14.  Setting  panel  state/visib 
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(0,  clear). 

(assert,  shown),  st_l_3_45) 
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(st_l_3_25, 

((0,  clear), 

(0,  write, "  TITLE:  ITEM  -  Creating. 

In  order  to  create  new  items  you  must  fust  select  the  panel  upon  which  the  new  item  will  be  placed.  Then  there  are  several  ways  to  create  items. 
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(click-continue,  (assert,  shown),  st_l_3_27_l), 
("CTc",  (assert,  shown),  st_l_3_27_l), 
(“NTn",  (assert,  shown),  st_  1  _3_27_  1 ))) 


((0,  clear), 

(0,  write, "  TITLE:  Data  Driven  Objects  (DDOs)  -  page  2  of  3. 

Lets  assume  you  want  to  incorporate  a  thermometer  stretcher  in  your  application.  'Select'  the  panel  on  which  the  thermometer  DDO  will  be  placed 
and  click  File/Include.  A  subwindow  will  appear  querying  the  user  for  the  name  of  the  file  to  be  included.  Type  '$TAEDEMO/res/sun4/ddodemo.res' 
in  the  response  area  and  return.  (Do  not  type  the  quote  marks,  just  the  name.)  A  new  window  will  open  that  contains  all  of  the  TAE+  provided  DDOs. 
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("PTp",  (assert,  shown),  st_l_3_27))) 
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user,  TAE+  appends  a  .res  extension  onto  the  filename. 
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(st_l_3_63, 

((0,  clear), 

(0,  write,  "  ...'opening  existing  file'  help  text  goes  here... "), 

(8,  write,  "Left-Middle-Righl  mouse  buttons  provide  subwindow,  function-  and  task-oriented  topic  lists  respectively. 
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(Eater  topic  number,  ’N’  for  next  function-oriented  page  or  ’P'  lor  previous  function-oriented  page)"), 

(8,  write,  "Left-Middle-Right  mouse  buttons  provide  subwindow,  function-  and  task-oriented  topic  lists  respectively. 
(9,  input,  mouse&key)). 
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("32'T33"r34’T36'T37T38T39'T40,T4rT’42",  st_l_3_175), 
sl_l_3_175)) 


(0,  write, "  43.  Panel  51.  Panel  Attributes 

44.  Creating  52.  Changing  panel  dimensions 

45.  Defining  inter-panel  connects  53.  Changing  panel  origin 

46.  Deleting  54.  Set  frame  chars 

47.  Editing/modifying  existing  55.  Set  preferred  panel  state 
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64.  Merging  (Include)  71.  Panel 

65.  Exiting  from  72.  Item 

66.  Saving  73.  Setting  the  interface  startup  mode 

67.  to  existing  file  74.  Using  Apply,  Cancel,  Close  or  OK  buttons 


(Enter  topic  number  or  'F  for  function-oriented  previous  page)"), 

(8,  write,  "Left-Middle-Right  mouse  buttons  provide  subwindow,  function-  and  task-oriented  topic  lists  respectively."), 
(9,  input,  mouse&key)), 

((click-left,  st_l_2_l),  /’•‘left  button  calls  for  sub-w  list*/ 

(click-middle,  sl_l_3_l),  /*middle  button  calls  for  function  list*/ 
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(8,  write,  "Left-Middle-Right  mouse  buttons  provide  subwindow,  function-  and  task-oriented  topic  lists  respectively. 
(9,  input,  mouse&key)), 

((click-left,  st_l_2_l),  /*left  button  calls  for  sub-w  list*/ 

(click-middle,  st_l_3_400),  /‘middle  button  calls  for  function  list*/ 

(click-right,  st_  1  _4_  I ) ,  /*right  button  calls  lor  task  list*/ 
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Ill 


/♦Non-novice  sees  specific  info  directly*/ 
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(st_l_4_28_2,  /*  user  answered  YES  to  query  re  used  other  types  of  TAE+  objects*/ 
((0,  clear), 

(0,  write, "  ...DDOs  ala  Selection/Text  objects... 

For  more  information  see  the  following  additional  topics: 


27.  Selecting  a  presentation  category 

32.  Selecting  a  presentation  type 

33.  DDO-->  Discrete  picture.  Mover,  Rotator 

Stretcher,  Strip  Chart  ”), 
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(st_l_4_60,  /*  originates  from  1_4_6  */ 
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(6,  write,  "Reluming  you  to  your  originating  menu  page...1 
(0,  pause,  5)), 
st_  1  _4_  1 ) 


((0,  write,  "  Selected  option  not  yet  implemented."), 

(6,  write,  "Reluming  you  to  your  originating  menu  page... 

(0,  pause,  5)), 

st_l_4_300) 
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("22TTwentytwoTtwentytwoTTWENTYTWO",  st_l_4_22), 
("25TTwentyfiveTtwentyfiveTTWEhnTFIVE\st_l_4_25). 
("26TTwentysixTtwentysixTTWEhnTSIX".st_l_4_26). 

("27TT  wentysevenTtwentysevenTTWENTY  SEVEN" ,  sl_l_4_27 ), 
("28TTwentyeightTtwentyeightTTWENTYEIGHT\st_l_4_28), 
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((O.clear), 

(0,  write,  "38.  Positioning  the  item  on  the  panel 

39.  Sizing  the  item  44.  LINKING  PANELS  WITH  PANEL  CONNECTIONS 

40.  Defining  item  appearance  45.  REHEARSING  THE  INTERFACE 

4 1 .  Specifying  item  default  value  46.  GENERATING  SOURCE  CODE 


42.  Specifying  item  details  47.  FINISHING  THE  INTERFACE 

43.  USING  ALIGNMENT  48.  Coding  the  event/event  stubs 

49.  QUITTING  TAE+ 
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APPENDIX  F 


CFD  GRAPH  GRAMMAR  (as  modified  Jan  93) 


(Extracted  from  [MASKE  92]) 

cfd_graph  ::=  cfd_graph  cfd_node  I  cfd_node  I  cfd_menu  cfd_node 

cfd_node  ::=  "("  cfd_id  actionjist responsejist ")"  I  identifier  string 

cfd_menu  ::=  "("  "menu"  string  menulist ")" 

menulist  ::=  string  cfdjd menulist  I  string  cfdjd 

cfdjd  ::=  identifier 

action_list  ::=  "("  act_node_list ")"  I  action_node 
response_list  ::=  "("  res_node_list ")"  I  response_node 
action_node  ::= "("  regionjd  action  ")" 
act_node_list  ::=  act_nodeJist ","  action_node  I  action_node 
response_node  ::=  ”("  pattern  ","  cfdjd  ”)" 

I "("  pattern "(H  "assert" identifier ")" cfdjd  ”)" 

I "("  pattern "ignore" ")" 

I  "("  pattern  "("  "assert"  identifier  ")"  "ignore"  T 
I "("  "assert" identifier ")"  ",M  cfdjd  I  cfdjd 
res_nodeJist  ::=  res_nodeJist response_node  I  response_node 
regionjd  ::=  integer  I  regionjd "+"  integer 
action  "draw"  identfier 
I  "draw"  identifier  location 
I  "clear"  I  "clear"  \"  identifier  location 
I  "write"  string  I  "input"  ","  inputjist 
I  "pause" integer  I  "drag"  identifier 
I  "quit"  I  "retract" cfdjd identifier 
inputjist  ::=  "mouse"  I  "keyboard"  I  "mouse&key" 
location  ::= "("  loc_part loc_part ")" 
loc_part  ::=  loc_part "+"  term  I  loc_part term  I  term 
term  ::=  term  "*"  factor  I  term  T  factor  I  factor 
factor  ::=  integer  I  "mouseX”  I  "mouseY" 

1  identifier  ".x"  1  identifier  ".y" 

I  "halfwid"  I  "halfltt" 

I  ”("  loc_part ")" 

patpart  keywords  I  "click-left"  I  "click-right"  I  "click-middle" 

I  "click-any"  I  loc_part  relop  loc_part  I  "click-exit"  I  "click-help" 

I  "click-continue"  I  "mouse-move"  I  integer  "seconds" 

I  "past"  cfdjd  identifier  I "("  pattern  ”)" 
patconj  ::=  patpart  I  patconj  "&"  patpart 
pattern  ::=  patconj  I  pattern  "I"  patconj 
relop  ::=  "="  I  ">"  I  "<"  I  ">="  I  "<=" 
keywords  ::=  string 
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